| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
Makes sure that a deserialized macro is only added to the preprocessor macro definitions only once.
Unfortunately I couldn't get a reduced test case.
rdar://13016031
llvm-svn: 172843
|
|
|
|
| |
llvm-svn: 172808
|
|
|
|
|
|
|
| |
complicated modules (<rdar://problem/13038265>). Unfortunately, this
un-fixes <rdar://problem/13016031>.
llvm-svn: 172783
|
|
|
|
|
|
| |
is used outside of a preprocessor directive. This fixes PR14837.
llvm-svn: 172639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would serialize the macro redefinitions as a list, part of
the identifier, and try to chain them together across modules individually
without having the info that they were already chained at definition time.
Change this by serializing the macro redefinition chain and then try
to synthesize the chain parts across modules. This allows us to correctly
pinpoint when 2 different definitions are ambiguous because they came from
unrelated modules.
Fixes bogus "ambiguous expansion of macro" warning when a macro in a PCH
is redefined without undef'ing it first.
rdar://13016031
llvm-svn: 172620
|
|
|
|
| |
llvm-svn: 172555
|
|
|
|
|
|
| |
callers, removing unneeded const_cast
llvm-svn: 172372
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
| |
<rdar://problem/12748859>.
llvm-svn: 171939
|
|
|
|
|
|
|
|
| |
keyword for ObjC properties.
Fixes <rdar://problem/12953378>.
llvm-svn: 171504
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
|
|
| |
reached EOF and did not expand the argument into the source context.
llvm-svn: 170980
|
|
|
|
|
|
| |
a not-fully-formed macro invocation during code-completion.
llvm-svn: 170833
|
|
|
|
|
|
|
|
| |
the macro invocation is not fully formed.
rdar://11290992
llvm-svn: 170824
|
|
|
|
| |
llvm-svn: 170686
|
|
|
|
| |
llvm-svn: 170314
|
|
|
|
|
|
| |
a note about where the macro is defined.
llvm-svn: 170228
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 168778
|
|
|
|
| |
llvm-svn: 168274
|
|
|
|
|
|
|
| |
__has_attribute, __has_extension, making them behave more akin to
conventional macros.
llvm-svn: 168268
|
|
|
|
| |
llvm-svn: 168267
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
common LexStringLiteral function. In doing so, some consistency problems have
been ironed out (e.g. where the first token in the string literal was lexed
with macro expansion, but subsequent ones were not) and also an erroneous
diagnostic has been corrected.
LexStringLiteral is complemented by a FinishLexStringLiteral function which
can be used in the situation where the first token of the string literal has
already been lexed.
llvm-svn: 168266
|
|
|
|
| |
llvm-svn: 168265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the related comma pasting extension.
In certain cases, we used to get two diagnostics for what is essentially one
extension. This change suppresses the first diagnostic in certain cases
where we know we're going to print the second diagnostic. The
diagnostic is redundant, and it can't be suppressed in the definition
of the macro because it points at the use of the macro, so we want to
avoid printing it if possible.
The implementation works by detecting constructs which look like comma
pasting at the time of the definition of the macro; this information
is then used when the macro is used. (We can't actually detect
whether we're using the comma pasting extension until the macro is
actually used, but we can detecting constructs which will be comma
pasting if the varargs argument is elided.)
<rdar://problem/12292192>
llvm-svn: 167907
|
|
|
|
|
|
| |
*Sanitizer to Sanitize* in preparation for later patches.
llvm-svn: 167405
|
|
|
|
|
|
| |
expressions involving __has_include
llvm-svn: 166438
|
|
|
|
|
|
| |
#undef only occurs if that submodule is imported.
llvm-svn: 165773
|
|
|
|
|
|
|
| |
only with modules, when two disjoint modules #define the same
identifier to different token sequences.
llvm-svn: 165746
|
|
|
|
|
|
| |
associated with deserializing macro history for an identifier.
llvm-svn: 165729
|
|
|
|
| |
llvm-svn: 165683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
macro history.
When deserializing macro history, we arrange history such that the
macros that have definitions (that haven't been #undef'd) and are
visible come at the beginning of the list, which is what the
preprocessor and other clients of Preprocessor::getMacroInfo()
expect. If additional macro definitions become visible later, they'll
be moved toward the front of the list. Note that it's possible to have
ambiguities, but we don't diagnose them yet.
There is a partially-implemented design decision here that, if a
particular identifier has been defined or #undef'd within the
translation unit, that definition (or #undef) hides any macro
definitions that come from imported modules. There's still a little
work to do to ensure that the right #undef'ing happens.
Additionally, we'll need to scope the update records for #undefs, so
they only kick in when the submodule containing that update record
becomes visible.
llvm-svn: 165682
|
|
|
|
|
|
|
| |
Add a test for PR13924. Do not revert the test added in r163022,
it surprisingly still passes even after reverting the code changes.
llvm-svn: 164672
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
specific module (__building_module(modulename)) and to get the name of
the current module as an identifier (__MODULE__).
Used to help headers behave differently when they're being included as
part of building a module. Oh, the irony.
llvm-svn: 164605
|
|
|
|
| |
llvm-svn: 164555
|
|
|
|
| |
llvm-svn: 164554
|
|
|
|
| |
llvm-svn: 163023
|
|
|
|
|
|
| |
considering commas from nested macro expansions as argument separators. Fixes parsing of VS 2012 headers.
llvm-svn: 163022
|
|
|
|
|
|
|
|
|
| |
(__is_pod, __is_signed, etc.) to normal identifiers if they are
encountered in certain places in the grammar where we know that prior
versions of libstdc++ or libc++ use them, to still allow the use of
these keywords as type traits. Fixes <rdar://problem/9836262> and PR10184.
llvm-svn: 162937
|
|
|
|
|
|
|
|
| |
within its own argument list. The original definition is used for the immediate
expansion, but the new definition is used for any subsequent occurences within
the argument list or after the expansion.
llvm-svn: 162906
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The problem was with the following sequence:
#pragma push_macro("long")
#undef long
#pragma pop_macro("long")
in case when "long" didn't represent a macro.
Fixed crash and removed code duplication for #undef/pop_macro case. Added regression tests.
Reviewers: doug.gregor, klimek
Reviewed By: doug.gregor
CC: cfe-commits, chapuni
Differential Revision: http://llvm-reviews.chandlerc.com/D31
llvm-svn: 162845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
diagnostics for bad deployment targets and adding a few
more predicates. Includes a patch by Jonathan Schleifer
to enable ARC for ObjFW.
llvm-svn: 162252
|
|
|
|
|
|
| |
per Richard's comment.
llvm-svn: 161786
|
|
|
|
|
|
| |
function attribute. // rdar://10253857
llvm-svn: 161767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This tests for the ability to include a "message" field in availability
attributes, like so:
extern void ATSFontGetName(const char *oName)
__attribute__((availability(macosx,introduced=8.0,deprecated=9.0,
message="use CTFontCopyFullName")));
This was actually supported in Clang 3.1, but we got a request for a
__has_feature so that header files can use this more safely. It's
unfortunate that the 3.1 release doesn't include this, however.
<rdar://problem/11886458>
llvm-svn: 160699
|
|
|
|
| |
llvm-svn: 160622
|
|
|
|
|
|
|
| |
the current version of clang understands __attribute__((unused)) on
fields.
llvm-svn: 159252
|
|
|
|
| |
llvm-svn: 159054
|