types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85500 91177308-0d34-0410-b5e6-96231b3b80d8
which should come from the variable and wasn't correct for arrays in any case.
No change in functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85415 91177308-0d34-0410-b5e6-96231b3b80d8
process decl attributes instead of dropping them on the floor.
This allows us to diagnose cases like the testcase. Also don't
diagnose deprecated stuff in ActOnTag: not all uses of tags
may be 'uses', and SemaType does this now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85071 91177308-0d34-0410-b5e6-96231b3b80d8
types) out of Sema::getTypeName into ConvertDeclSpecToType. getTypeName
is sometimes used as a predicate in the parser, so it could cause redundant
diags to be emitted. This is also needed by two upcoming enhancements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85070 91177308-0d34-0410-b5e6-96231b3b80d8
IIDecl cannot be null. There is no need to check for both C++ mode and
presence of CXXRecordDecl. ObjC interfaces can't have ScopeSpecs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85057 91177308-0d34-0410-b5e6-96231b3b80d8
type looking using getTypeName() and every property access was using
NextToken() to do lookahead to see if the identifier is followed by
a '.'. Rearrange this code to not need lookahead and only do the
type lookup if we have "identifier." in the token stream. Also
improve a diagnostic a bit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85056 91177308-0d34-0410-b5e6-96231b3b80d8
template instantiation. Preserve it through PCH. Show it off to the indexer.
I'm healthily ignoring the vector type cases because we don't have a sensible
TypeLoc implementation for them anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84994 91177308-0d34-0410-b5e6-96231b3b80d8
in the DeclaratorInfo, if one is present.
Preserve source information through template instantiation. This is made
more complicated by the possibility that ParmVarDecls don't have DIs, which
is possibly worth fixing in the future.
Also preserve source information for function parameters in ObjC method
declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84971 91177308-0d34-0410-b5e6-96231b3b80d8
to all callers. Switch a few other users of CK_Unknown to proper cast
kinds.
Note that there are still some situations where we end up with
CK_Unknown; they're pretty easy to find with grep. There
are still a few missing conversion kinds, specifically
pointer/int/float->bool and the various combinations of real/complex
float/int->real/complex float/int.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84623 91177308-0d34-0410-b5e6-96231b3b80d8
TypeLoc records for declarations; it should not be necessary to represent it
directly in the type system.
Please complain if you were using these classes and feel you can't replicate
previous functionality using the TypeLoc API.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84222 91177308-0d34-0410-b5e6-96231b3b80d8
unknown type name, e.g.,
foo::bar x;
when "bar" does not refer to a type in "foo".
With this change, the parser now calls into the action to perform
diagnostics and can try to recover by substituting in an appropriate
type. For example, this allows us to easily diagnose some missing
"typename" specifiers, which we now do:
test/SemaCXX/unknown-type-name.cpp:29:1: error: missing 'typename'
prior to dependent type name 'A<T>::type'
A<T>::type A<T>::f() { return type(); }
^~~~~~~~~~
typename
Fixes PR3990.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84053 91177308-0d34-0410-b5e6-96231b3b80d8
what we found when we looked into <blah>", where <blah> is a
DeclContext*. We can now format DeclContext*'s in nice ways, e.g.,
"namespace N", "the global namespace", "'class Foo'".
This is part of PR3990, but we're not quite there yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84028 91177308-0d34-0410-b5e6-96231b3b80d8
template as a specialization. For example, this occurs with:
template<typename T>
struct X {
template<typename U> struct Inner { /* ... */ };
};
template<> template<typename T>
struct X<int>::Inner {
T member;
};
We need to treat templates that are member specializations as special
in two contexts:
- When looking for a definition of a member template, we look
through the instantiation chain until we hit the primary template
*or a member specialization*. This allows us to distinguish
between the primary "Inner" definition and the X<int>::Inner
definition, above.
- When computing all of the levels of template arguments needed to
instantiate a member template, don't add template arguments
from contexts outside of the instantiation of a member
specialization, since the user has already manually substituted
those arguments.
Fix up the existing test for p18, which was actually wrong (but we
didn't diagnose it because of our poor handling of member
specializations of templates), and add a new test for member
specializations of templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83974 91177308-0d34-0410-b5e6-96231b3b80d8
function templates.
This commit ensures that friend function templates are constructed as
FunctionTemplateDecls rather than partial FunctionDecls (as they
previously were). It then implements template instantiation for friend
function templates, injecting the friend function template only when
no previous declaration exists at the time of instantiation.
Oh, and make sure that explicit specialization declarations are not
friends.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83970 91177308-0d34-0410-b5e6-96231b3b80d8
that are declarations (rather than definitions). Also, be sure to set
the access specifiers properly when instantiating the declarations of
member function templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83911 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation has already been required. To do so, keep track of the
point of instantiation for anything that can be instantiated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83890 91177308-0d34-0410-b5e6-96231b3b80d8
Split the various ambiguous result enumerators into their own enum. Tests
for most of C++ [namespace.qual].
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83700 91177308-0d34-0410-b5e6-96231b3b80d8
Also, eliminate a redundant diagnostic by marking a variable declared
with incomplete type as an invalid declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83553 91177308-0d34-0410-b5e6-96231b3b80d8
function and member function templates that are not definitions. Add
more tests to ensure that explicit specializations of member function
templates prevent instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83550 91177308-0d34-0410-b5e6-96231b3b80d8
templates, and keep track of how those member classes were
instantiated or specialized.
Make sure that we don't try to instantiate an explicitly-specialized
member class of a class template, when that explicit specialization
was a declaration rather than a definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83547 91177308-0d34-0410-b5e6-96231b3b80d8
track of the kind of specialization or instantiation. Also, check the
scope of the specialization and ensure that a specialization
declaration without an initializer is not a definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83533 91177308-0d34-0410-b5e6-96231b3b80d8
templates. Previously, these weren't handled as specializations at
all. The AST for representing these as specializations is still a work
in progress.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83498 91177308-0d34-0410-b5e6-96231b3b80d8
for bases, members, overridden virtual methods, etc. The operations
isDerivedFrom and lookupInBases are now provided by CXXRecordDecl,
rather than by Sema, so that CodeGen and other clients can use them
directly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83396 91177308-0d34-0410-b5e6-96231b3b80d8
of the flow-control checks for falling off the end of a function,
since the return type may instantiate to void. Similarly, if a
return statement has an expression and the return type of the function
is void, don't complain if the expression is type-dependent, since
that type could instantiate to void.
Fixes PR5071.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83222 91177308-0d34-0410-b5e6-96231b3b80d8
functions that occur in multiple declaration contexts, e.g., because
some were found via using declarations. Now, isDeclInScope will build
a new overload set (when needed) containing only those declarations
that are actually in scope. This eliminates a problem found with
libstdc++'s <iostream>, where the presence of using
In the longer term, I'd like to eliminate Sema::isDeclInScope in favor
of better handling of the RedeclarationOnly flag in the name-lookup
routines. That way, name lookup only returns the entities that matter,
rather than taking the current two-pass approach of producing too many
results and then filtering our the wrong results. It's not efficient,
and I'm sure that we aren't filtering everywhere we should be.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82954 91177308-0d34-0410-b5e6-96231b3b80d8
class templates. We now treat friend class templates much more like
normal class templates, except that they still get special name lookup
rules. Fixes PR5057 and eliminates a bunch of spurious diagnostics in
<iostream>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82848 91177308-0d34-0410-b5e6-96231b3b80d8
template void f<int>(int);
~~~~~~
Previously, we silently dropped the template arguments. With this
change, we now use the template arguments (when available) as the
explicitly-specified template arguments used to aid template argument
deduction for explicit template instantiations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82806 91177308-0d34-0410-b5e6-96231b3b80d8
first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks
There are many caveats here:
- We completely and totally drop any explicitly-specified template
arguments on the floor
- We don't diagnose any of the extra semantic things that we should
diagnose.
- I haven't looked to see that we're getting the right linkage for
explicit specializations
On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82728 91177308-0d34-0410-b5e6-96231b3b80d8
John McCall
Fariborz Jahanian
Douglas Gregor
Mike Stump
Ted Kremenek
Chris Lattner
Sebastian Redl
Eli Friedman
Daniel Dunbar
Tanya Lattner