deduction. Unify all of the looping over template arguments for
deduction purposes into a single place, where argument pack expansion
occurs; this is also the hook for deducing from pack expansions, which
itself is not yet implemented.
For now, at least we can handle a basic "count" metafunction written
with variadics. See the new test for the formulation that works.
llvm-svn: 122418
This change is necessary when the variable is a const reference and we need
the l-value of the construct expr. After that, when binding the variable,
recover the lazy compound value when the variable is not a reference.
In Environment, use the value of a no-op cast expression when it has one.
Otherwise, blast-through it.
llvm-svn: 122388
inconsistent with the type that the builtin *should* have, forget
about the builtin altogether: we don't want subsequence analyses,
CodeGen, etc., to think that we have a proper builtin function.
C is protected from errors here because it allows one to use a
library builtin without having a declaration, and detects inconsistent
(re-)declarations of builtins during declaration merging. C++ was
unprotected, and therefore would crash.
Fixes PR8839.
llvm-svn: 122351
take into account the region of interest. Otherwise, we may fail to
traverse some important preprocessed entity cursors.
Fixes <rdar://problem/8554072>.
llvm-svn: 122350
classes, categories, protocols, and class extensions, where the
methods and properties of these entities would be inserted into the
DeclContext in an ordering that doesn't necessarily reflect source
order. The culprits were Sema::ActOnMethodDeclaration(), which did not
perform the insertion of the just-created method declaration into
the DeclContext for these Objective-C entities, and
Sema::ActOnAtEnd(), which inserted all method declarations at the
*end* of the DeclContext.
With this fix in hand, clean up the code-completion actions for
property setters/getters that worked around this brokenness in the AST.
Fixes <rdar://problem/8062781>, where this problem manifested as poor
token-annotation information, but this would have struck again in many
other places.
llvm-svn: 122347
unknown type and there is a possibility that
at runtime method is resolved to a deprecated or
unavailable method. Addreses // rdar://8769853
llvm-svn: 122294
whose patterns are template arguments. We can now instantiate, e.g.,
typedef tuple<pair<OuterTypes, InnerTypes>...> type;
where OuterTypes and InnerTypes are template type parameter packs.
There is a horrible inefficiency in
TemplateArgumentLoc::getPackExpansionPattern(), where we need to
create copies of TypeLoc data because our interfaces traffic in
TypeSourceInfo pointers where they should traffic in TypeLocs
instead. I've isolated in efficiency in this one routine; once we
refactor our interfaces to traffic in TypeLocs, we can eliminate it.
llvm-svn: 122278
a parameter pack, check the parameter pack against each of the
template arguments it corresponds to, then pack the converted
arguments into a template argument pack. Allows us to use variadic
class templates so long as instantiation isn't required, e.g.,
template<typename... Types> struct Tuple;
Tuple<int, float> *t2;
llvm-svn: 122251
pack expansions, e.g. given
template<typename... Types> struct tuple;
template<typename... Types>
struct tuple_of_refs {
typedef tuple<Types&...> types;
};
the type of the "types" typedef is a PackExpansionType whose pattern
is Types&.
This commit introduces support for creating pack expansions for
template type arguments, as above, but not for any other kind of pack
expansion, nor for any form of instantiation.
llvm-svn: 122223
test due to recent changes to the CFG. The
diagnostic is somewhat in the wrong place, but
the -Wunreachable-code diagnostic needs to be
revamped anyway since most of the diagnostics
in this test case are redundant.
llvm-svn: 121961
implicit lvalue-to-rvalue casts that John McCall
recently introduced. This causes a whole bunch
of logic in the analyzer for handling lvalues
to vanish. It does, however, raise a few issues
in the analyzer w.r.t to modeling various constructs
(e.g., field accesses to compound literals).
The .c/.m analysis test cases that fail are
due to a missing lvalue-to-rvalue cast that
will get introduced into the AST. The .cpp
failures were more than I could investigate in
one go, and the patch was already getting huge.
I have XFAILED some of these tests, and they
should obviously be further investigated.
Some highlights of this patch include:
- CFG no longer requires an lvalue bit for
CFGElements
- StackFrameContext doesn't need an 'asLValue'
flag
- The "VisitLValue" path from GRExprEngine has
been eliminated.
Besides the test case failures (XFAILed), there
are surely other bugs that are fallout from
this change.
llvm-svn: 121960
declarations. This is a work in progress, as I go through the C++
declaration grammar to identify where unexpanded parameter packs can
occur.
llvm-svn: 121912
parameter packs within a statement, type, etc. Use this visitor to
provide improved diagnostics for the presence of unexpanded parameter
packs in a full expression, base type, declaration type, etc., by
highlighting the unexpanded parameter packs and providing their names,
e.g.,
test/CXX/temp/temp.decls/temp.variadic/p5.cpp:28:85: error: declaration type
contains unexpanded parameter packs 'VeryInnerTypes',
'OuterTypes', ...
...VeryInnerTypes, OuterTypes>, pair<InnerTypes, OuterTypes> > types;
~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~ ^
llvm-svn: 121883
Diagnostic pragmas are broken because we don't keep track of the diagnostic state changes and we only check the current/latest state.
Problems manifest if a diagnostic is emitted for a source line that has different diagnostic state than the current state; this can affect
a lot of places, like C++ inline methods, template instantiations, the lexer, etc.
Fix the issue by having the Diagnostic object keep track of the source location of the pragmas so that it is able to know what is the diagnostic state at any given source location.
Fixes rdar://8365684.
llvm-svn: 121873
BuildExpressionFromIntegralTemplateArgument can produce malformed
IntegerLiterals with an EnumType if the template parameter type
is an EnumType. This breaks the AST printer which expects all
IntegerLiterals to have a plain integer type. Instead, give the
IntegerLiteral the enum's promotion type and wrap in an implicit cast
to the EnumType.
llvm-svn: 121862
within the class. Teach IR gen to look for function definitions in record
lexical contexts when deciding whether to emit a function whose address
was taken. Fixes PR8789.
llvm-svn: 121833
whether the expression contains an unexpanded parameter pack, in the
same vein as the changes to the Type hierarchy. Compute this bit
within all of the Expr subclasses.
This change required a bunch of reshuffling of dependency
calculations, mainly to consolidate them inside the constructors and
to fuse multiple loops that iterate over arguments to determine type
dependence, value dependence, and (now) containment of unexpanded
parameter packs.
Again, testing is painfully sparse, because all of the diagnostics
will change and it is more important to test the to-be-written visitor
that collects unexpanded parameter packs.
llvm-svn: 121831
and TemplateArgument with an operation that determines whether there
are any unexpanded parameter packs within that construct. Use this
information to diagnose the appearance of the names of parameter packs
that have not been expanded (C++ [temp.variadic]p5). Since this
property is checked often (every declaration, ever expression
statement, etc.), we extend Type and Expr with a bit storing the
result of this computation, rather than walking the AST each time to
determine whether any unexpanded parameter packs occur.
This commit is deficient in several ways, which will be remedied with
future commits:
- Expr has a bit to store the presence of an unexpanded parameter
pack, but it is never set.
- The error messages don't point out where the unexpanded parameter
packs were named in the type/expression, but they should.
- We don't check for unexpanded parameter packs in all of the places
where we should.
- Testing is sparse, pending the resolution of the above three
issues.
llvm-svn: 121724
would return true if the initializer pointer union had *any* non-null
pointer in it, even if the pointer wasn't one that would actually be
returned via getInit(). This makes it more accurately model the logic of
'getInit() != NULL'.
This still isn't completely satisfying. From a principled stance,
I suspect we should make hasInit() and getInit() *always* return false
and NULL (resp.) for ParmVarDecl. We shouldn't at the API level treat
initializers and default arguments as the same thing.
llvm-svn: 121692
declared setter or getter in current class extension or one
of the other class extensions. Mark them as synthesized as
property will be synthesized when property with same name is
seen in the @implementation. This prevents bogus warning
about unimplemented methods to be issued for these methods.
Fixes // rdar://8747333
llvm-svn: 121597
We should not substitute template types if the template has a dependent
context because the template argument stack is not yet fully formed.
Instead, defer substitution until the template has a non-dependent
context (i.e. instantiation of an outer template).
llvm-svn: 121491
visibility. Fixes PR8713.
I've disabled a test which was testing that you can #pragma pop visibility
to get out of a namespace's visibility attribute. We should probably just
diagnose that as an error unless it's instrumental to someone's system
headers.
llvm-svn: 121459
global code completions are disabled (e.g., because they are
cached). Also, make sure that forward-declared protocols are visited
when we look for all visible names within a declaration context.
Previously, we would end up with duplicate completions for protocols.
llvm-svn: 121416
"inline", we weren't giving the definition weak linkage because the
"inline" bit wasn't propagated. This was a longstanding FIXME that,
somehow, hadn't triggered a bug in the wild. Fix this problem by
tracking whether any declaration was marked "inline", and clean up the
semantics of GNU's "extern inline" semantics calculation based on this
change.
Fixes <rdar://problem/8740363>.
llvm-svn: 121373
declaration that is a value in ill-formed code. Instead of crashing,
treat this as a dependent typename specifier and suggest that the
using add "typename" into the using declaration. Fixes <rdar://problem/8740998>.
llvm-svn: 121322
cv-qualification conversions. More specifically, there's an implicit
cv-qualification conversion (even one that drops qualifiers) when
converting to 'id' or qualified 'id'. Fixes <rdar://problem/8734046>.
llvm-svn: 121047
Douglas Gregor