DeclContext has a little less than 8 bytes free due to the alignment
requirements on 64 bits archs. This set of patches moves the
bit-fields from classes deriving from DeclContext into DeclContext.
On 32 bits archs this increases the size of DeclContext by 4 bytes
but this is balanced by an equal or larger reduction in the size
of the classes deriving from it.
On 64 bits archs the size of DeclContext stays the same but
most of the classes deriving from it shrink by 8/16 bytes.
(-print-stats diff here https://reviews.llvm.org/D49728)
When doing an -fsyntax-only on all of Boost this result
in a 3.6% reduction in the size of all Decls and
a 1% reduction in the run time due to the lower cache
miss rate.
For now CXXRecordDecl is not touched but there is
an easy 6 (if I count correctly) bytes gain available there
by moving some bits from DefinitionData into the free
space of DeclContext. This will be the subject of another patch.
This patch sequence also enable the possibility of refactoring
FunctionDecl: To save space some bits from classes deriving from
FunctionDecl were moved to FunctionDecl. This resulted in a
lot of stuff in FunctionDecl which do not belong logically to it.
After this set of patches however it is just a simple matter of
adding a SomethingDeclBitfields in DeclContext and moving the
bits to it from FunctionDecl.
This first patch introduces the anonymous union in DeclContext
and all the *DeclBitfields classes holding the bit-fields, and moves
the bits from TagDecl, EnumDecl and RecordDecl into DeclContext.
This patch is followed by https://reviews.llvm.org/D49732,
https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734.
Differential Revision: https://reviews.llvm.org/D49729
Patch By: bricci
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338630 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is a tweak of changyu's patch: https://reviews.llvm.org/D40381. It differs in that the recognition of the 'concept' token is moved into the machinery that recognizes declaration-specifiers - this allows us to leverage the attribute handling machinery more seamlessly.
See the test file to get a sense of the basic parsing that this patch supports.
There is much more work to be done before concepts are usable...
Thanks Changyu!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@330794 91177308-0d34-0410-b5e6-96231b3b80d8
whether they have an initializer.
We cannot distinguish between a declaration of a variable template
specialization and a definition of one that lacks an initializer without this,
and would previously mistake the latter for the former.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319605 91177308-0d34-0410-b5e6-96231b3b80d8
These functions were defined as static members of TemplateSpecializationType.
Now they are moved to namespace level. Previously there were different
implementations for lists containing TemplateArgument and TemplateArgumentLoc,
now these implementations share the same code.
This change is a result of refactoring patch D40508. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319178 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like the only use of AddDeallocation is to indirectly call the
destructors of objects. In one case I found
(TypeAliasTemplateDecl::Common), the destructor is a nop, so registering
it to run later seems pointless.
All of the other *::Common types have non-trivial dtors, so deleting the
useless AddDeallocation felt somewhat fragile. Happy to kill it + turn
the is_trivial_dtor check into a static_assert if people think that'd be
better.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295029 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This adds associated constraints as a property of class templates.
An error is produced if redeclarations are not similarly constrained.
Reviewers: rsmith, faisalv, aaron.ballman
Reviewed By: rsmith
Subscribers: cfe-commits, nwilson
Differential Revision: https://reviews.llvm.org/D25674
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294697 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes a crash in modules where the template class decl becomes the most recent
decl in the redeclaration chain and forcing the template instantiator try to
instantiate the friend declaration, rather than the template definition.
In practice, A::list<int> produces a TemplateSpecializationType
A::__1::list<int, allocator<type-parameter-0-0> >' failing to replace to
subsitute the default argument to allocator<int>.
Kudos Richard Smith (D28399).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291753 91177308-0d34-0410-b5e6-96231b3b80d8
template arguments as written rather than the canonical template arguments,
so we print more user-friendly names for template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290483 91177308-0d34-0410-b5e6-96231b3b80d8
out of an internal function and into ASTContext; this is needed in template
argument deduction for P0522R0.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290405 91177308-0d34-0410-b5e6-96231b3b80d8
After r256463, both the LHS and RHS now refer to the same variable. Before,
they referred to the member, the parameter respectively. Now GCC6's
-Wtautological-compare complains.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288444 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Space for storing the //constraint-expression// of the
//requires-clause// associated with a `TemplateParameterList` is
arranged by taking a bit out of the `NumParams` field for the purpose
of determining whether there is a //requires-clause// or not, and by
adding to the trailing objects tied to the `TemplateParameterList`. An
accessor is provided.
An appropriate argument is supplied to `TemplateParameterList::Create`
at the various call sites.
Serialization changes will addressed as the Concepts implementation
becomes more solid.
Drive-by fix:
This change also replaces the custom
`FixedSizeTemplateParameterListStorage` implementation with one that
follows the interface provided by `llvm::TrailingObjects`.
Reviewers: aaron.ballman, faisalv, rsmith
Subscribers: cfe-commits, nwilson
Differential Revision: https://reviews.llvm.org/D19322
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276069 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length
pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274732 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274601 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274475 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a __nth_element builtin that allows fetching the n-th type of a
parameter pack with very little compile-time overhead. The patch was inspired by
r252036 and r252115 by David Majnemer, which add a similar __make_integer_seq
builtin for efficiently creating a std::integer_sequence.
Reviewed as D15421. http://reviews.llvm.org/D15421
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274316 91177308-0d34-0410-b5e6-96231b3b80d8
This new builtin template allows for incredibly fast instantiations of
templates like std::integer_sequence.
Performance numbers follow:
My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz.
__make_integer_seq<std::integer_sequence, int, 90000> takes 0.25
seconds.
std::make_integer_sequence<int, 90000> takes unbound time, it is still
running. Clang is consuming gigabytes of memory.
Differential Revision: http://reviews.llvm.org/D13786
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252036 91177308-0d34-0410-b5e6-96231b3b80d8
modules, and allow use of a default template argument if any of the parameters
providing it is visible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239485 91177308-0d34-0410-b5e6-96231b3b80d8
This is just a preparatory step towards fixing visibility for default template
arguments in modules builds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239447 91177308-0d34-0410-b5e6-96231b3b80d8
attempting to lazily deserialize its specializations; otherwise, there might be
pending specializations that we don't know about yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230301 91177308-0d34-0410-b5e6-96231b3b80d8
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209046 91177308-0d34-0410-b5e6-96231b3b80d8
can't accidentally be allocated the wrong way (missing prefix data for decls
from AST files, for instance) and simplifies the CreateDeserialized functions a
little. An extra DeclContext* parameter to the not-from-AST-file operator new
allows us to ensure that we don't accidentally call the wrong one when
deserializing (when we don't have a DeclContext), allows some extra checks, and
prepares for some planned modules-related changes to Decl allocation.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195426 91177308-0d34-0410-b5e6-96231b3b80d8
This was only used to ensure that the traversal order was the same as the
insertion order, but that guarantee was already being provided by the use
of a FoldingSetVector.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189075 91177308-0d34-0410-b5e6-96231b3b80d8
Stephen Kelly