Commit Graph

382 Commits

Author SHA1 Message Date
Douglas Gregor bb1196534c When we see a 'template' disambiguator that marks the next identifier
(or operator-function-id) as a template, but the context is actually
non-dependent or the current instantiation, allow us to use knowledge
of what kind of template it is, e.g., type template vs. function
template, for further syntactic disambiguation. This allows us to
parse properly in the presence of stray "template" keywords, which is
necessary in C++0x and it's good recovery in C++98/03.

llvm-svn: 106167
2010-06-16 23:00:59 +00:00
Douglas Gregor f7d7771812 Fix the recently-added warning about 'typename' and 'template'
disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.

llvm-svn: 106161
2010-06-16 22:31:08 +00:00
Douglas Gregor 010815a20b Downgrade the error when using a typedef in the nested-name-specifier
of an explicit instantiation to an ExtWarn, since nobody else seems to
diagnose this problem.

llvm-svn: 106109
2010-06-16 16:26:47 +00:00
Douglas Gregor 2ebcae1931 Revert r106099; it broke self-host.
llvm-svn: 106100
2010-06-16 15:23:05 +00:00
Abramo Bagnara bec18dbb88 Added TemplateTypeParmType::getDecl().
llvm-svn: 106099
2010-06-16 14:59:30 +00:00
John McCall e9cccd86da Fix a point of semantics with using declaration hiding: method templates
introduced by using decls are hidden even if their template parameter lists
or return types differ from the "overriding" declaration.

Propagate using shadow declarations around more effectively when looking up
template-ids.  Reperform lookup for template-ids in member expressions so that
access control is properly set up.

Fix some number of latent bugs involving template-ids with totally invalid
base types.  You can only actually get these with a scope specifier, since
otherwise the template-id won't parse as a template-id.

Fixes PR7384.

llvm-svn: 106093
2010-06-16 08:42:20 +00:00
Douglas Gregor b90df60b3b Introduce Type::isIntegralOrEnumerationType(), to cover those places
in C++ that involve both integral and enumeration types. Convert all
of the callers to Type::isIntegralType() that are meant to work with
both integral and enumeration types over to
Type::isIntegralOrEnumerationType(), to prepare to eliminate
enumeration types as integral types.

llvm-svn: 106071
2010-06-16 00:17:44 +00:00
Douglas Gregor 20527e2c83 Allocate template parameter lists for out-of-line definitions via the
ASTContext rather than via the normal heap.

llvm-svn: 106008
2010-06-15 17:44:38 +00:00
Douglas Gregor c9d2682df3 Warn when a 'typename' or a 'template' keyword refers to a
non-dependent type or template name, respectively, in C++98/03. Fixes
PR7111 and <rdar://problem/8002682>.

llvm-svn: 105968
2010-06-14 22:07:54 +00:00
John McCall 30576cdce3 TemplateSpecializationType's isCurrentInstantiation bit can be derived
from its canonical type.

llvm-svn: 105912
2010-06-13 09:25:03 +00:00
Abramo Bagnara da41d0cf5b Added template parameters info for out-of-line definitions of class template methods.
llvm-svn: 105882
2010-06-12 08:15:14 +00:00
Abramo Bagnara 8075c85230 Don't omit class explicit instantiation from AST.
llvm-svn: 105880
2010-06-12 07:44:57 +00:00
John McCall c392f37ae8 Split DependentNameType into two types. DependentNameType represents the
case of an elaborated-type-specifier like 'typename A<T>::foo', and
DependentTemplateSpecializationType represents the case of an
elaborated-type-specifier like 'typename A<T>::template B<T>'.  The TypeLoc
representation of a DependentTST conveniently exactly matches that of an
ElaboratedType wrapping a TST.

Kill off the explicit rebuild methods for RebuildInCurrentInstantiation;
the standard implementations work fine because the nested name specifier
is computable in the newly-entered context.

llvm-svn: 105801
2010-06-11 00:33:02 +00:00
Abramo Bagnara 656e300f03 Added inherited info to template and non-type arguments of templates.
llvm-svn: 105716
2010-06-09 09:26:05 +00:00
Jeffrey Yasskin 2f96e9f5c9 Add an extension to avoid an error when a global template has the same name as
a member template, and you try to call the member template with an explicit
template argument.  See PR7247 

For example, this downgrades the error to a warning in:

template<typename T> struct set{};
struct Value {
    template<typename T>
    void set(T value) {
    }
};
void foo() {
    Value v;
    v.set<double>(3.2);  // Warning here.
}

llvm-svn: 105518
2010-06-05 01:39:57 +00:00
John McCall 8cb7bdfd33 Alter the interface of GetTypeForDeclarator to return a TypeSourceInfo*.
This is never null, but the associated type might be.

llvm-svn: 105503
2010-06-04 23:28:52 +00:00
Douglas Gregor 2e87ca218f When checking for equality of template parameter lists, a template
type parameter pack is distinct from a template type parameter.

llvm-svn: 105464
2010-06-04 08:34:32 +00:00
John McCall f7bcc81213 Copy source information for the inner type of an elaborated type; fixes some
valgrind problems.

llvm-svn: 105062
2010-05-28 23:32:21 +00:00
Douglas Gregor a09387df9f It turns out that people love using VLAs in templates, too. Weaken our
VLA restrictions so that one can use VLAs in templates (even
accidentally), but not as part of a non-type template parameter (which
would be very bad).

llvm-svn: 104471
2010-05-23 19:57:01 +00:00
Douglas Gregor 30a4f4c757 Provide the overloaded functions for UnresolvedLookupExpr and
UnresolvedMemberExpr in their constructors, rather than adding them
after the fact. No functionality change.

llvm-svn: 104468
2010-05-23 18:57:34 +00:00
Douglas Gregor 959d5a0cbd Implement support for variable length arrays in C++. VLAs are limited
in several important ways:

  - VLAs of non-POD types are not permitted.
  - VLAs cannot be used in conjunction with C++ templates.

These restrictions are intended to keep VLAs out of the parts of the
C++ type system where they cause the most trouble. Fixes PR5678 and
<rdar://problem/8013618>.

llvm-svn: 104443
2010-05-22 16:17:30 +00:00
Douglas Gregor 20c38a7c58 Improve recovery when we see a dependent template name that is missing
the required "template" keyword, using the same heuristics we do for
dependent template names in member access expressions, e.g.,

test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template'
      keyword to treat 'getAs' as a dependent template name
    T::getAs<U>();
       ^
       template 

Fixes PR5404.

llvm-svn: 104409
2010-05-21 23:43:39 +00:00
Douglas Gregor 786123dc48 Improve parser recovery when we encounter a dependent template name
that is missing the 'template' keyword, e.g., 

  t->getAs<T>()

where getAs is a member of an unknown specialization. C++ requires
that we treat "getAs" as a value, but that would fail to parse since T
is the name of a type. We would then fail at the '>', since a type
cannot be followed by a '>'.

This is a very common error for C++ programmers to make, especially
since GCC occasionally allows it when it shouldn't (as does Visual
C++). So, when we are in this case, we use tentative parsing to see if
the tokens starting at "<" can only be parsed as a template argument
list. If so, we produce a diagnostic with a fix-it that states that
the 'template' keyword is needed:

test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword
      is required to treat 'getAs' as a dependent template name
    t->getAs<T>();
       ^
       template 

This is just a start of this patch; I'd like to apply the same
approach to everywhere that a template-id with dependent template name
can be parsed.

llvm-svn: 104406
2010-05-21 23:18:07 +00:00
Abramo Bagnara 02ccd28a92 Added TemplateArgumentListInfo to FunctionTemplateSpecializationInfo.
llvm-svn: 104226
2010-05-20 15:32:11 +00:00
Abramo Bagnara 1108e7b873 Renamed misleading getSourceRange -> getLocalSourceRange and getFullSourceRange -> getSourceRange for TypeLoc.
llvm-svn: 104220
2010-05-20 10:00:11 +00:00
John McCall 87fe5d5618 Support implicitly closing on 'this' in a block. Fixed PR7165.
(the codegen works here, too, but that's annoying to test without execution)

llvm-svn: 104202
2010-05-20 01:18:31 +00:00
Chris Lattner ce7a22d97c fix the TemplateArgumentList copy constructor to not
be a copy constructor (since it isn't one semantically)
and fix the ownership bits it sets to be correct!

llvm-svn: 104192
2010-05-20 00:19:09 +00:00
Abramo Bagnara d754848f10 Added basic source locations to Elaborated and DependentName types.
llvm-svn: 104169
2010-05-19 21:37:53 +00:00
Daniel Dunbar 4707cef758 Revert r103770, "Added basic source locations to Elaborated and DependentName
types.", it is breaking Clang bootstrap.

llvm-svn: 103775
2010-05-14 16:34:09 +00:00
Abramo Bagnara e9f4d6ed7d Added basic source locations to Elaborated and DependentName types.
llvm-svn: 103770
2010-05-14 14:14:23 +00:00
Douglas Gregor 88d292ccb8 Rework when and how vtables are emitted, by tracking where vtables are
"used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions. 

The new scheme:
  - For every use of a vtable, Sema calls MarkVTableUsed() to indicate
  the use. For example, this occurs when calling a virtual member
  function of the class, defining a constructor of that class type,
  dynamic_cast'ing from that type to a derived class, casting
  to/through a virtual base class, etc.
  - For every definition of a vtable, Sema calls MarkVTableUsed() to
  indicate the definition. This happens at the end of the translation
  unit for classes whose key function has been defined (so we can
  delay computation of the key function; see PR6564), and will also
  occur with explicit template instantiation definitions.
 - For every vtable defined/used, we mark all of the virtual member
 functions of that vtable as defined/used, unless we know that the key
 function is in another translation unit. This instantiates virtual
 member functions when needed.
  - At the end of the translation unit, Sema tells CodeGen (via the
  ASTConsumer) which vtables must be defined (CodeGen will define
  them) and which may be used (for which CodeGen will define the
  vtables lazily). 

From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).

Notes:
  (1) There's a ton of churn in the tests, because the order in which
  vtables get emitted to IR has changed. I've tried to isolate some of
  the larger tests from these issues.
  (2) Some diagnostics related to
  implicitly-instantiated/implicitly-defined virtual member functions
  have moved to the point of first use/definition. It's better this
  way.
  (3) I could use a review of the places where we MarkVTableUsed, to
  see if I missed any place where the language effectively requires a
  vtable.

Fixes PR7114 and PR6564.

llvm-svn: 103718
2010-05-13 16:44:06 +00:00
Abramo Bagnara 6150c884df Merged Elaborated and QualifiedName types.
llvm-svn: 103517
2010-05-11 21:36:43 +00:00
Douglas Gregor c97d7a2c6a The C++98/03 standard is disturbingly silent about out-of-scope
explicit instantiations of template. C++0x clarifies the intent
(they're ill-formed in some cases; see [temp.explicit] for
details). However, one could squint at the C++98/03 standard and
conclude they are permitted, so reduce the error to a warning
(controlled by -Wc++0x-compat) in C++98/03 mode.

llvm-svn: 103482
2010-05-11 17:39:34 +00:00
Douglas Gregor e902956f59 Partial and full specializations of a class template may have a
different tag kind ("struct" vs. "class") than the primary template,
which has an affect on access control.

Should fix the last remaining Boost.Accumulors failure.

llvm-svn: 103144
2010-05-06 00:28:52 +00:00
Douglas Gregor b22ee88652 Support for 'template' as a disambiguator (PR7030)
ParseOptionalCXXScopeSpecifier() only annotates the subset of
    template-ids which are not subject to lexical ambiguity. Add support
    for the more general case in ParseUnqualifiedId() to handle cases
    such as A::template B().

    Also improve some diagnostic locations.

Fixes PR7030, from Alp Toker!

llvm-svn: 103081
2010-05-05 05:58:24 +00:00
John McCall 0b66eb38c7 It turns out that basically every caller to RequireCompleteDeclContext
already knows what context it's looking in.  Just pass that context in
instead of (questionably) recalculating it.

llvm-svn: 102818
2010-05-01 00:40:08 +00:00
Douglas Gregor fabf95d066 After substituting a template argument for a non-type template
parameter with pointer-to-member type, we may have to perform a
qualification conversion, since the pointee type of the parameter
might be more qualified than the pointee type of the argument we form
from the declaration. Fixes PR6986.

llvm-svn: 102777
2010-04-30 21:46:38 +00:00
Douglas Gregor 14cf752486 Clean up our handling of local instantiation scopes, which keep track
of the mapping from local declarations to their instantiated
counterparts during template instantiation. Previously, we tried to do
some unholy merging of local instantiation scopes that involved
storing a single hash table along with an "undo" list on the
side... which was ugly, and never handled function parameters
properly.

Now, we just keep separate hash tables for each local instantiation
scope, and "combining" two scopes means that we'll look in each of the
combined hash tables. The combined scope stack is rarely deep, and
this makes it easy to avoid the "undo" issues we were hitting. Also,
I've simplified the logic for function parameters: if we're declaring
a function and we need the function parameters to live longer, we just
push them back into the local instantiation scope where we need them. 

Fixes PR6990.

llvm-svn: 102732
2010-04-30 18:55:50 +00:00
Douglas Gregor 407e961645 Introduce a sequence number into class template partial
specializations, which keeps track of the order in which they were
originally declared. We use this number so that we can always walk the
list of partial specializations in a predictable order during matching
or template instantiation. This also fixes a failure in Boost.Proto,
where SourceManager::isBeforeInTranslationUnit was behaving
poorly in inconsistent ways.

llvm-svn: 102693
2010-04-30 05:56:50 +00:00
John McCall 99b2fe5f54 Rebuild the nested name specifiers in member-pointer declarator chunks when
entering the current instantiation.  Set up a little to preserve type location
information for typename types while we're in there.

Fixes a Boost failure.

llvm-svn: 102673
2010-04-29 23:50:39 +00:00
Douglas Gregor 33dcc2e34d It turns out that we *can* end up having to display template argument
bindings when the template argument is still an expression; it happens
while checking the template arguments of a class template partial
specializations. Fixes PR6964.

llvm-svn: 102595
2010-04-29 04:55:13 +00:00
John McCall 2408e32096 Make the InjectedClassNameType the canonical type of the current instantiation
of a class template or class template partial specialization.  That is to
say, in
  template <class T> class A { ... };
or
  template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context.  This allows us to track the
current instantiation appropriately even inside AST routines.  It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).

llvm-svn: 102407
2010-04-27 00:57:59 +00:00
Douglas Gregor 53ce178cef When we take the address of a declaration to bind it to a non-type
template parameter, by sure to mark that declaration as
"referenced". The Boost.Iterator library now passes all tests.

llvm-svn: 102256
2010-04-24 18:20:53 +00:00
Anders Carlsson 0c509eeac7 CastExpr should not hold a pointer to the base path. More cleanup.
llvm-svn: 102249
2010-04-24 16:57:13 +00:00
Douglas Gregor ba41d01b59 Be more careful around dependent nested-name-specifiers, complaining
when they are not complete (since we could not match them up to
anything) and ensuring that enum parsing can cope with dependent
elaborated-type-specifiers. Fixes PR6915 and PR6649.

llvm-svn: 102247
2010-04-24 16:38:41 +00:00
Douglas Gregor bbdf20acd0 Keep track of when DependentNameTypes have no associated keyword
(e.g., no typename, enum, class, etc.), e.g., because the context is
one that is known to refer to a type. Patch from Enea Zaffanella!

llvm-svn: 102243
2010-04-24 15:35:55 +00:00
Anders Carlsson 9759793855 Add an InheritancePath parameter to the ImplicitCastExpr constructor.
llvm-svn: 102218
2010-04-23 22:18:37 +00:00
Douglas Gregor b74b1038bb C++ [namespace.memdef]p3 only applies when the friend is not named via
a qualified name. We weren't checking for an empty
nested-name-specifier when dealing with friend class templates
(although we were checking in the other places where we deal with this
paragraph). Fixes a Boost.Serialization showstopper.

llvm-svn: 101724
2010-04-18 17:37:40 +00:00
Douglas Gregor b8eaf2944b Audit uses of Sema::LookupSingleName for those lookups that are
intended for redeclarations, fixing those that need it. Fixes PR6831.

This uncovered an issue where the C++ type-specifier-seq parsing logic
would try to perform name lookup on an identifier after it already had
a type-specifier, which could also lead to spurious ambiguity errors
(as in PR6831, but with a different test case).

llvm-svn: 101419
2010-04-15 23:40:53 +00:00
Douglas Gregor b2ccf010fb Feed proper source-location information into Sema::LookupSingleResult,
in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting). Noticed while working on PR6831.

llvm-svn: 101412
2010-04-15 22:33:43 +00:00