| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
declarations of the current primary module.
llvm-svn: 165046
|
| |
|
|
|
|
| |
entities of the current primary module.
llvm-svn: 165023
|
| |
|
|
|
|
| |
resulted in an automatic module import.
llvm-svn: 165022
|
| |
|
|
|
|
|
|
| |
the merging should have set it correctly.
This is especially relevant for templatedDecls that might be injected (and thus have their DeclContext set to) somewhere completely different.
llvm-svn: 165005
|
| |
|
|
|
|
| |
the ASTConsumer.
llvm-svn: 165001
|
| |
|
|
|
|
|
|
|
|
|
| |
Check whether a pending instantiation needs to be instantiated (or whether an instantiation already exists).
Verify the size of the PendingInstantiations record (was only checking size of existing PendingInstantiations).
Migrate Obj-C++ part of redecl-merge into separate test, now that this is growing.
templates.mm: test that CodeGen has seen exactly one definition of template instantiations.
redecl-merge.m: use "@" specifier for expected-diagnostics.
llvm-svn: 164993
|
| |
|
|
|
|
|
|
| |
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
|
| |
|
|
|
|
|
|
| |
Lookup can nevertheless find them due to the serialized lookup table.
For instance when reading a template decl's templatedDecl, it will search for existing decls that it could be a redeclaration of, and find the half-read template decl.
Thus there is no point in asserting the names of decls.
llvm-svn: 164932
|
| |
|
|
|
|
| |
Don't require specializations (of existing and read template) to be unique.
llvm-svn: 164931
|
| |
|
|
|
|
|
|
|
| |
specialization was written, which is non-canonical at the time of reading: force the reading of the ClassTemplateDecl if it was written.
The easiest way out is to store whether the decl was canonical at the time of writing.
Add test.
llvm-svn: 164927
|
| |
|
|
|
|
|
|
|
|
|
|
| |
enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.
<rdar://problem/12296776>.
llvm-svn: 164656
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
latest macro definition. Needs more work.
Summary: Passes all tests (+ the new one with code completion), but needs a thorough review in part related to modules.
Reviewers: doug.gregor
Reviewed By: alexfh
CC: cfe-commits, rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D41
llvm-svn: 164610
|
| |
|
|
|
|
|
| |
the fact. Test cases will come when we're actually (de-)serializing
macro history.
llvm-svn: 164549
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
but not
external visible decls, call DeclContext::setMustBuildLookupTable so that the
"lazy decls" bit of the LookupPtr is set.
Previously, in non-C++, if there were no new declarations causing the "lazy decls" bit
to be set, then DeclContext::lookups_begin() would fail to return the decls from the PCH.
Fixes rdar://12316296.
llvm-svn: 164351
|
| |
|
|
| |
llvm-svn: 164335
|
| |
|
|
|
|
|
|
| |
clang has recently started to warn about the enum compares:
lib/Serialization/ASTWriter.cpp:2760:31: warning: comparison of literal 256 with expression of type
'clang::DeclarationName::NameKind' is always true [-Wtautological-constant-out-of-range-compare]
llvm-svn: 164220
|
| |
|
|
|
|
|
|
| |
definition info; it needs to be there because the mangler needs to
access it before we're finished defining the lambda class.
PR12808.
llvm-svn: 164186
|
| |
|
|
|
|
| |
changes.
llvm-svn: 164106
|
| |
|
|
| |
llvm-svn: 163983
|
| |
|
|
| |
llvm-svn: 163863
|
| |
|
|
|
|
|
| |
parameter packs where the reference is not being expanded but the pack has
been. Previously, Clang would segfault in such cases.
llvm-svn: 163672
|
| |
|
|
|
|
| |
Unfortunately, no test case. rdar://11960120
llvm-svn: 163566
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 163149
|
| |
|
|
|
|
| |
Also a minor fix to __except printing in StmtPrinter.cpp. Thanks to Aaron Ballman for review.
llvm-svn: 163083
|
| |
|
|
| |
llvm-svn: 163032
|
| |
|
|
|
|
| |
instead of aliasing to "struct" which had some incorrect behaviour. Patch by David Robins.
llvm-svn: 163013
|
| |
|
|
|
|
|
|
|
| |
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Summary: Keep history of macro definitions and #undefs with corresponding source locations, so that we can later find out all macros active in a specified source location. We don't save the history in PCH (no need currently). Memory overhead is about sizeof(void*)*3*<number of macro definitions and #undefs>+<in-memory size of all #undef'd macros>
I've run a test on a file composed of 109 .h files from boost 1.49 on x86-64 linux.
Stats before this patch:
*** Preprocessor Stats:
73222 directives found:
19171 #define.
4345 #undef.
#include/#include_next/#import:
5233 source files entered.
27 max include stack depth
19210 #if/#ifndef/#ifdef.
2384 #else/#elif.
6891 #endif.
408 #pragma.
14466 #if/#ifndef#ifdef regions skipped
80023/451669/1270 obj/fn/builtin macros expanded, 85724 on the fast path.
127145 token paste (##) operations performed, 11008 on the fast path.
Preprocessor Memory: 5874615B total
BumpPtr: 4399104
Macro Expanded Tokens: 417768
Predefines Buffer: 8135
Macros: 1048576
#pragma push_macro Info: 0
Poison Reasons: 1024
Comment Handlers: 8
Stats with this patch:
...
Preprocessor Memory: 7541687B total
BumpPtr: 6066176
Macro Expanded Tokens: 417768
Predefines Buffer: 8135
Macros: 1048576
#pragma push_macro Info: 0
Poison Reasons: 1024
Comment Handlers: 8
In my test increase in memory usage is about 1.7Mb, which is ~28% of initial preprocessor's memory usage and about 0.8% of clang's total VMM allocation.
As for CPU overhead, it should only be noticeable when iterating over all macros, and should mostly consist of couple extra dereferences and one comparison per macro + skipping of #undef'd macros. It's less trivial to measure, though, as the preprocessor consumes a very small fraction of compilation time.
Reviewers: doug.gregor, klimek, rsmith, djasper
Reviewed By: doug.gregor
CC: cfe-commits, chandlerc
Differential Revision: http://llvm-reviews.chandlerc.com/D28
llvm-svn: 162810
|
| |
|
|
|
|
| |
change intended.
llvm-svn: 162710
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 162632
|
| |
|
|
| |
llvm-svn: 162629
|
| |
|
|
| |
llvm-svn: 162506
|
| |
|
|
| |
llvm-svn: 162361
|
| |
|
|
| |
llvm-svn: 162210
|
| |
|
|
|
|
|
| |
information on FunctionProtoType. (This also fixes one of *many* misalignment
problems in the TypeLoc hierarchy...)
llvm-svn: 161901
|
| |
|
|
| |
llvm-svn: 160851
|
| |
|
|
| |
llvm-svn: 160850
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
|
| |
|
|
|
|
|
|
| |
previous ResetObjCLayout calls since this is now handled in Sema.
Part of rdar://11842763
llvm-svn: 160527
|
| |
|
|
|
|
|
| |
static_assert fails when parsing the template, don't diagnose it again on every
instantiation.
llvm-svn: 160088
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as "volatile", meaning there's a high enough chance that they may
change while we are trying to use them.
This flag is only enabled by libclang.
Currently "volatile" source files will be stat'ed immediately
before opening them, because the file size stat info
may not be accurate since when we got it (e.g. from the PCH).
This avoids crashes when trying to reference mmap'ed memory
from a file whose size is not what we expect.
Note that there's still a window for a racing issue to occur
but the window for it should be way smaller than before.
We can consider later on to avoid mmap completely on such files.
rdar://11612916
llvm-svn: 160074
|
| |
|
|
| |
llvm-svn: 159954
|
| |
|
|
| |
llvm-svn: 159925
|
| |
|
|
|
|
|
|
| |
currently we take address of std::vector's contents only after we finished
adding all comments (so no reallocation can happen), this will change in
future.
llvm-svn: 159845
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
very simple semantic analysis that just builds the AST; minor changes for lexer
to pick up source locations I didn't think about before.
Comments AST is modelled along the ideas of HTML AST: block and inline content.
* Block content is a paragraph or a command that has a paragraph as an argument
or verbatim command.
* Inline content is placed within some block. Inline content includes plain
text, inline commands and HTML as tag soup.
llvm-svn: 159790
|
| |
|
|
| |
llvm-svn: 159723
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
coming from an AST file are registered for serialization.
A static data member instantiation of in a chained PCH could be missed
when serializing decls; the result was that when emitting the visible decls
map of its DeclContext, we would use a DeclID that was not actually emitted,
leading to crashes or hangs.
Fix this by making sure such decls are always registered for serialization.
Also introduce extra sanity checks to make sure we don't register new
declarations or types after we have serialized the types/decls block.
rdar://11728990
llvm-svn: 159550
|
| |
|
|
|
|
|
|
|
|
| |
For some targets a structure named __va_list_tag is built to help define
the __builtin_va_list type. However, __va_list_tag was not being treated as a
predefined type thus causing problems when serializing the AST. This commit
fixes that oversight by adding the necessary support to treat __va_list_tag
as a predefined type.
llvm-svn: 159508
|
| |
|
|
|
|
|
|
|
| |
express library-level dependencies within Clang.
This is no more verbose really, and plays nicer with the rest of the
CMake facilities. It should also have no change in functionality.
llvm-svn: 158888
|