Commit Graph

135 Commits

Author SHA1 Message Date
Dmitri Gribenko f857950d39 Remove useless 'llvm::' qualifier from names like StringRef and others that are
brought into 'clang' namespace by clang/Basic/LLVM.h

llvm-svn: 172323
2013-01-12 19:30:44 +00:00
Chandler Carruth 3a02247dc9 Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237
2012-12-04 09:13:33 +00:00
Abramo Bagnara c76dcbdc0c Fixed ClassTemplateSpecializationDecl source range.
llvm-svn: 165975
2012-10-15 21:06:42 +00:00
Richard Smith 1fde8ece37 PR9023: A template template parameter whose template parameter list contains an
unexpanded parameter pack is a pack expansion. Thus, as with a non-type template
parameter which is a pack expansion, it needs to be expanded early into a fixed
list of template parameters.

Since the expanded list of template parameters is not itself a parameter pack,
it is permitted to appear before the end of the template parameter list, so also
remove that restriction (for both template template parameter pack expansions and
non-type template parameter pack expansions).

llvm-svn: 163369
2012-09-07 02:06:42 +00:00
Richard Smith 426f78555e Fix misaligned allocation of TemplateParameterList objects.
llvm-svn: 162056
2012-08-16 22:51:34 +00:00
Nico Weber 7b5a716f3d Make explicit specializations at class scope work
for non-type template parameters in microsoft mode.
PR12709.

llvm-svn: 159147
2012-06-25 17:21:05 +00:00
Chandler Carruth b41171b70b Fix non-deterministic iteration order when walking the specializations
of templates by using the newly introduce FoldingSetVector. This
preserves insertion order for all iteration of specializations.

I've also included a somewhat terrifying testcase that rapidly builds up
a large number of functions. This is enough that any system with ASLR
will have non-deterministic debug information generated for the test
case without the fix here as the debug information is generated in part
by walking these specializations.

llvm-svn: 156133
2012-05-03 23:49:05 +00:00
Douglas Gregor ce9978ff1f When we form a new function/class template specialization, we first
search for the specialization (in a folding set) and, if not found
form a *Decl that is then inserted into that folding set. In rare
cases, the folding set may be reallocated between the search and the
insertion, causing a crash. No test case, because triggering rehashing
consistently in a small test case is not feasible. Fixes
<rdar://problem/11115071>.

llvm-svn: 153575
2012-03-28 14:34:23 +00:00
John McCall 113bee0536 Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to
track whether the referenced declaration comes from an enclosing
local context.  I'm amenable to suggestions about the exact meaning
of this bit.

llvm-svn: 152491
2012-03-10 09:33:50 +00:00
Douglas Gregor ec9fd13c77 De-virtualize getPreviousDecl() and getMostRecentDecl() when we know
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).

Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.

llvm-svn: 148187
2012-01-14 16:38:05 +00:00
Douglas Gregor 463c8e7070 Add a FIXME for mutation of the common pointer of a RedeclarableTemplateDecl. It is not clear that it's worth delaying the allocation of said pointer
llvm-svn: 148182
2012-01-14 15:30:55 +00:00
Douglas Gregor 68444de354 Reimplement RedeclarableTemplateDecl in terms of
Redeclarable<RedeclarableTemplateDecl>, eliminating a bunch of
redeclaration-chain logic both in RedeclarableTemplateDecl and
especially in its (de-)serialization.

As part of this, eliminate the RedeclarableTemplate<> class template,
which was an abstraction that didn't actually save anything.

llvm-svn: 148181
2012-01-14 15:13:49 +00:00
Douglas Gregor 72172e9009 When creating declarations that are deserialized from an module file,
go through a central allocation routine
Decl::AllocateDeserializedDecl(). No actual functionality change (yet).

llvm-svn: 147614
2012-01-05 21:55:30 +00:00
David Blaikie 68e081d606 Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146959
2011-12-20 02:48:34 +00:00
Abramo Bagnara fd3a455ac7 Fixed source range for template implicit instantiations.
llvm-svn: 141018
2011-10-03 20:34:03 +00:00
Argyrios Kyrtzidis e9a24435c6 Don't use TemplateArgumentListInfo inside AST nodes because it may leak.
Use ASTTemplateArgumentListInfo instead.

llvm-svn: 140331
2011-09-22 20:07:09 +00:00
Chris Lattner 0e62c1cc0b remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports
them into the clang namespace.

llvm-svn: 135852
2011-07-23 10:55:15 +00:00
Richard Smith 3f1b5d077b Implement support for C++0x alias templates.
llvm-svn: 130953
2011-05-05 21:57:07 +00:00
Chandler Carruth 0883632acb Re-applies the patch first applied way back in r106099, with
accompanying fixes to make it work today.

The core of this patch is to provide a link from a TemplateTypeParmType
back to the TemplateTypeParmDecl node which declared it. This in turn
provides much more precise information about the type, where it came
from, and how it functions for AST consumers.

To make the patch work almost a year after its first attempt, it needed
serialization support, and it now retains the old getName() interface.
Finally, it requires us to not attempt to instantiate the type in an
unsupported friend decl -- specifically those coming from template
friend decls but which refer to a specific type through a dependent
name.

A cleaner representation of the last item would be to build
FriendTemplateDecl nodes for these, storing their template parameters
etc, and to perform proper instantation of them like any other template
declaration. They can still be flagged as unsupported for the purpose of
access checking, etc.

This passed an asserts-enabled bootstrap for me, and the reduced test
case mentioned in the original review thread no longer causes issues,
likely fixed at somewhere amidst the 24k revisions that have elapsed.

llvm-svn: 130628
2011-05-01 00:51:33 +00:00
Sebastian Redl 9ab988fe00 Chained PCH: Remember when additional specializations are added to a function template from a previous PCH. Fixes the only crasher when using massive chains on Clang's Sema component. We still have some incomplete codegen there.
llvm-svn: 129516
2011-04-14 14:07:59 +00:00
Abramo Bagnara 29c2d46786 Fixed InnerLocStart.
llvm-svn: 127330
2011-03-09 14:09:51 +00:00
Abramo Bagnara ea94788cf4 Fixed source range for StaticAssertDecl and LinkageSpecDecl. Fixed source range for declarations using postfix types.
llvm-svn: 127251
2011-03-08 16:41:52 +00:00
Abramo Bagnara dff1930bf7 Fixed source range for all DeclaratorDecl's.
llvm-svn: 127225
2011-03-08 08:55:46 +00:00
Abramo Bagnara b3185b00c5 Fixed TypedefDecl and TemplateTypeParameter source range.
llvm-svn: 127119
2011-03-06 15:48:19 +00:00
Douglas Gregor 43669f84ed When determining template instantiation arguments within a function
template (not a specialization!), use the "injected" function template
arguments, which correspond to the template parameters of the function
template. This is required when substituting into the default template
parameters of template template parameters within a function template.

Fixes PR9016.

llvm-svn: 127092
2011-03-05 17:54:25 +00:00
Douglas Gregor 3c41bf740f *Recursively* set the context of a template parameter, so that we also
capture the template parameters of template template parameters.

llvm-svn: 127012
2011-03-04 18:32:38 +00:00
Douglas Gregor fd7c225530 Make sure to put template parameters into their owning template's
DeclContext once we've created it. This mirrors what we do for
function parameters, where the parameters start out with
translation-unit context and then are adopted by the appropriate
DeclContext when it is created. Also give template parameters public
access and make sure that they don't show up for the purposes of name
lookup.

Fixes PR9400, a regression introduced by r126920, which implemented
substitution of default template arguments provided in template
template parameters (C++ core issue 150).

How on earth could the DeclContext of a template parameter affect the
handling of default template arguments?

I'm so glad you asked! The link is
Sema::getTemplateInstantiationArgs(), which determines the outer
template argument lists that correspond to a given declaration. When
we're instantiating a default template argument for a template
template parameter within the body of a template definition (not it's
instantiation, per core issue 150), we weren't getting any outer
template arguments because the context of the template template
parameter was the translation unit. Now that the context of the
template template parameter is its owning template, we get the
template arguments from the injected-class-name of the owning
template, so substitution works as it should.

llvm-svn: 127004
2011-03-04 17:52:15 +00:00
Abramo Bagnara a0935267dc Fixed source range for ClassTemplateSpecializationDecl.
llvm-svn: 126999
2011-03-04 14:20:30 +00:00
Abramo Bagnara 23485e04be Improved TemplateTypeParmDecl end location.
llvm-svn: 126996
2011-03-04 12:42:03 +00:00
Abramo Bagnara e15d553663 Fixed end location of NonTypeTemplateParamDecl.
llvm-svn: 126994
2011-03-04 11:03:48 +00:00
Douglas Gregor b11aad8cba Revert all of my commits that devirtualized the Decl hierarchy, which
lead to a serious slowdown (4%) on parsing of Cocoa.h. This memory
optimization should be revisited later, when we have time to look at
the generated code.

llvm-svn: 126033
2011-02-19 18:51:44 +00:00
Douglas Gregor fe590dfa84 Devirtualize DeclaratorDecl::getInnerLocStart() and TagDecl::getInnerLocStart().
llvm-svn: 125754
2011-02-17 17:39:40 +00:00
Douglas Gregor a991f3a4e9 Devirtualize NamedDecl::getNameForDiagnostic().
llvm-svn: 125751
2011-02-17 17:23:19 +00:00
Douglas Gregor 0215459c37 Devirtualize RedeclarableTemplateDecl::newCommon().
llvm-svn: 125750
2011-02-17 17:10:20 +00:00
John McCall f4cd4f94d9 NonTypeTemplateParmDecl is just a DeclaratorDecl, not a VarDecl.
Also, reorganize and make very explicit the logic for determining
the value kind and type of a referenced declaration.

llvm-svn: 125150
2011-02-09 01:13:10 +00:00
Douglas Gregor 0231d8dac7 Implement support for non-type template parameter packs whose type is
a pack expansion, e.g., the parameter pack Values in:

  template<typename ...Types>
  struct Outer {
    template<Types ...Values>
    struct Inner;
  };

This new implementation approach introduces the notion of an
"expanded" non-type template parameter pack, for which we have already
expanded the types of the parameter pack (to, say, "int*, float*",
for Outer<int*, float*>) but have not yet expanded the values. Aside
from creating these expanded non-type template parameter packs, this
patch updates template argument checking and non-type template
parameter pack instantiation to make use of the appropriate types in
the parameter pack.

llvm-svn: 123845
2011-01-19 20:10:05 +00:00
Douglas Gregor e1d60df0fc Teach template template argument pack expansions to keep track of the
number of expansions, when we know it, and propagate that information
through Sema.

llvm-svn: 123493
2011-01-14 23:41:42 +00:00
Douglas Gregor b884000ba9 Teach PackExpansionExpr to keep track of the number of pack expansions
it will expand to, if known. Propagate this information throughout Sema.

llvm-svn: 123470
2011-01-14 21:20:45 +00:00
Douglas Gregor 0dca5fdb4e Keep track of the number of expansions to be produced from a type pack
expansion, when it is known due to the substitution of an out
parameter pack. This allows us to properly handle substitution into
pack expansions that involve multiple parameter packs at different
template parameter levels, even when this substitution happens one
level at a time (as with partial specializations of member class
templates and the signatures of member function templates).

Note that the diagnostic we provide when there is an arity mismatch
between an outer parameter pack and an inner parameter pack in this
case isn't as clear as the normal diagnostic for an arity
mismatch. However, this doesn't matter because these cases are very,
very rare and (even then) only typically occur in a SFINAE context.

The other kinds of pack expansions (expression, template, etc.) still
need to support optional tracking of the number of expansions, and we
need the moral equivalent of SubstTemplateTypeParmPackType for
substituted argument packs of template template and non-type template
parameters.

llvm-svn: 123448
2011-01-14 17:04:44 +00:00
Jay Foad 39c7980772 PR3558: mark "logically const" accessor methods in ASTContext as const,
and mark the fields they use as mutable. This allows us to remove a few
const_casts.

llvm-svn: 123314
2011-01-12 09:06:06 +00:00
Douglas Gregor 74c6d19c1f Add TemplateArgument::CreatePackCopy() to create a new parameter pack
in ASTContext-allocated memory, copying the provided template
arguments. Use this new routine where we can. No functionality change.

llvm-svn: 123289
2011-01-11 23:09:57 +00:00
Douglas Gregor eb29d18e5d Add semantic analysis for the creation of and an AST representation
for template template argument pack expansions. This allows fun such
as: 

  template<template<class> class ...> struct apply_impl { /*...*/ };
  template<template<class> class ...Metafunctions> struct apply {
    typedef typename apply_impl<Metafunctions...>::type type;
  };

However, neither template argument deduction nor template
instantiation is implemented for template template argument packs, so
this functionality isn't useful yet.

I'll probably replace the encoding of template template
argument pack expansions in TemplateArgument so that it's harder to
accidentally forget about the expansion. However, this is a step in
the right general direction.

llvm-svn: 122890
2011-01-05 17:40:24 +00:00
Douglas Gregor f550077ef5 Implement support for template template parameter packs, e.g.,
template<template<class> class ...Metafunctions>
    struct apply_to_each;

llvm-svn: 122874
2011-01-05 15:48:55 +00:00
Douglas Gregor 857591143e When creating the injected-class-name for a class template involving a
non-type template parameter pack, make sure to create a pack expansion
for the corresponding template argument.

llvm-svn: 122799
2011-01-04 02:33:52 +00:00
Douglas Gregor da3cc0d3bf Add an AST representation for non-type template parameter
packs, e.g.,

  template<typename T, unsigned ...Dims> struct multi_array;

along with semantic analysis support for finding unexpanded non-type
template parameter packs in types, expressions, and so on.

Template instantiation involving non-type template parameter packs
probably doesn't work yet. That'll come soon.

llvm-svn: 122527
2010-12-23 23:51:58 +00:00
Douglas Gregor 8092e80095 When forming the injected-class-name of a variadic template, the
template argument corresponding to a template parameter pack is an
argument pack of a pack expansion of that template parameter
pack. Implements C++0x [temp.dep.type]p2 (at least, as much of it as
we can).

llvm-svn: 122498
2010-12-23 16:00:30 +00:00
John McCall 7decc9e4ea Calculate the value kind of an expression when it's created and
store it on the expression node.  Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.

Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.

llvm-svn: 119685
2010-11-18 06:31:45 +00:00
Douglas Gregor 1ccc8416a0 Remove broken support for variadic templates, along with the various
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.

But don't get too excited about that happening now.

llvm-svn: 118385
2010-11-07 23:05:16 +00:00
Argyrios Kyrtzidis 402dbbbd66 Use the ASTMutationListener to track added template specializations in a chained PCH.
llvm-svn: 117533
2010-10-28 07:38:42 +00:00
Douglas Gregor 7e8c4e061b Make AST deserialization for class template specializations lazier, by
not loading the specializations of a class template until some AST
consumer needs them.

llvm-svn: 117498
2010-10-27 22:21:36 +00:00