| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
hasAttribute. No functional changes.
llvm-svn: 205201
|
|
|
|
|
|
|
|
|
|
| |
Clean up the __has_attribute implementation without modifying its behavior.
Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes).
Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options.
llvm-svn: 205181
|
|
|
|
|
|
| |
results, some still have link errors.
llvm-svn: 204974
|
|
|
|
|
|
| |
with non-MSVC compilers.
llvm-svn: 204968
|
|
|
|
| |
llvm-svn: 204955
|
|
|
|
|
|
|
|
| |
Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes).
Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options.
llvm-svn: 204952
|
|
|
|
| |
llvm-svn: 204153
|
|
|
|
|
|
| |
its keywordliness.
llvm-svn: 203987
|
|
|
|
| |
llvm-svn: 202639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it, importers of B should not see the macro. This is complicated by the fact
that A's macro could also be visible through a different path. The rules (as
hashed out on cfe-commits) are included as a documentation update in this
change.
With this, the number of regressions in libc++'s testsuite when modules are
enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are
due to remaining bugs in this change (in particular, the handling of submodules
is imperfect).
llvm-svn: 202560
|
|
|
|
|
|
|
|
|
|
| |
This C++ feature has been marked complete since r191549, but the documentation
claimed it wasn't supported at all and the extension check misreported it as
being available in C.
No regression test; this was a short-lived typo.
llvm-svn: 199292
|
|
|
|
|
|
| |
whether an ARM target has the "interrupt" attribute, it will return true for ARM and MSP430 targets, and false for others.
llvm-svn: 198897
|
|
|
|
|
|
|
| |
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
|
|
|
|
|
|
|
|
|
|
| |
This is approaching consistency but the PP and Parse categories they still have
slightly different wording:
def err_pp_expected_after : Error<"missing %1 after %0">;
def err_expected_after : Error<"expected %1 after %0">;
llvm-svn: 198189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce proper facilities to render token spellings using the diagnostic
formatter.
Replaces most of the hard-coded diagnostic messages related to expected tokens,
which all shared the same semantics but had to be multiply defined due to
variations in token order or quote marks.
The associated parser changes are largely mechanical but they expose
commonality in whole chunks of the parser that can now be factored away.
This commit uses C++11 typed enums along with a speculative legacy fallback
until the transition is complete.
Requires corresponding changes in LLVM r197895.
llvm-svn: 197972
|
|
|
|
| |
llvm-svn: 196584
|
|
|
|
| |
llvm-svn: 196123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'final'
Summary: Some MS headers use these features.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1948
llvm-svn: 192936
|
|
|
|
|
|
| |
ABI mangling for qualified id<...>. Fixes <rdar://problem/14799110>.
llvm-svn: 192643
|
|
|
|
| |
llvm-svn: 191607
|
|
|
|
|
|
| |
here goes to Larisse Voufo.
llvm-svn: 191549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, Lex() would recurse whenever the current lexer changed (e.g.
upon entry into a macro). This patch turns the recursion into a loop: the
various lex routines now don't return a token when the current lexer changes,
and at the top level Preprocessor::Lex() now loops until it finds a token.
Normally, the recursion wouldn't end up being very deep, but the recursion depth
can explode in edge cases like a bunch of consecutive macros which expand to
nothing (like in the testcase test/Preprocessor/macro_expand_empty.c in this
patch).
<rdar://problem/14569770>
llvm-svn: 190980
|
|
|
|
|
|
|
|
|
| |
This removes __has_feature(objc_msg_lookup_stret), as it is not required
anymore after this patch.
Patch by Jonathan Schleifer!
llvm-svn: 190791
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike C++11's "thread_local" keyword, C11's "_Thread_local" is in the
reserved namespace, meaning we provide it unconditionally; it is marked
as KEYALL in TokenKinds.def.
This means that like all the other C11 keywords, we can expose its
presence through __has_extension().
llvm-svn: 190755
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D966
llvm-svn: 187925
|
|
|
|
|
|
| |
Patch by Ethan Jackson.
llvm-svn: 187365
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Beginning with svn r186971, we noticed an internal test started to fail when
using clang built with LTO. After much investigation, it turns out that there
are no blatant bugs here, we are just running out of stack space and crashing.
Preprocessor::ReadFunctionLikeMacroArgs already has one vector of 64 Tokens,
and r186971 added another. When built with LTO, that function is inlined into
Preprocessor::HandleMacroExpandedIdentifier, which for our internal test is
invoked in a deep recursive cycle. I'm leaving the original 64 Token vector
alone on the assumption that it is important for performance, but the new
FixedArgTokens vector is only used on an error path, so it should be OK if it
requires additional heap storage. It would be even better if we could avoid
the deep recursion, but I think this change is a good thing to do regardless.
<rdar://problem/14540345>
llvm-svn: 187315
|
|
|
|
|
|
|
|
|
| |
This allows the ObjFW runtime to correctly implement message forwarding
for messages which return a struct.
Patch by Jonathan Schleifer.
llvm-svn: 187174
|
|
|
|
|
|
|
|
| |
cxx_init_capture. "generalized" is neither descriptive nor future-proof. No
compatibility problems expected, since we've never advertised having this
feature.
llvm-svn: 187058
|
|
|
|
| |
llvm-svn: 187055
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function-like macro. Clang will attempt to correct the arguments by detecting
braced initializer lists:
1) If possible, suggest parentheses around arguments
containing braced lists which will give the proper number of arguments.
2) If a braced list is detected at the start of a macro argument, it cannot be
corrected by parentheses. Instead, just point out the location of these
braced lists.
llvm-svn: 186971
|
|
|
|
|
|
|
| |
with identifier info. This covers most identifier-like entities (other than
the ISO646 keywords).
llvm-svn: 185895
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows clang to parse the type_traits header in Visual Studio 2012,
which is included widely in practice.
This is a rework of r163022 by João Matos. The original patch broke
preprocessing of gtest headers, which this patch addresses.
Patch by Will Wilson!
llvm-svn: 184968
|
|
|
|
|
|
|
| |
headers may be included from within the module, but not from outside
the module.
llvm-svn: 184471
|
|
|
|
|
|
| |
completes the implementation of N3638.
llvm-svn: 181669
|
|
|
|
|
|
|
|
|
| |
provisional C++1y support.
Add __has_feature and __has_extension checks for C++1y features (based on the provisional names from
the C++ features study group), and update documentation to match.
llvm-svn: 181342
|
|
|
|
|
|
|
|
| |
MacroArgs object that provides information about
the argument tokens for a function macro.
llvm-svn: 181065
|
|
|
|
|
|
| |
__has_feature(cxx_thread_local) true when the target supports thread-local storage.
llvm-svn: 180909
|
|
|
|
| |
llvm-svn: 179861
|
|
|
|
|
|
|
|
|
|
| |
Also update "test/Modules/macros.c" to test modified semantics:
-When there is an ambiguous macro, expand using the latest introduced version, not the first one.
-#undefs in submodules cause the macro to not be exported by that submodule, it doesn't cause
undefining of macros in the translation unit that imported that submodule.
This reduces macro namespace interference across modules.
llvm-svn: 178105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroDirective's subclasses.
For each macro directive (define, undefine, visibility) have a separate object that gets chained
to the macro directive history. This has several benefits:
-No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like
PPMutationListener become unnecessary.
-No need to keep extra source locations for the undef/visibility locations for the define directive object
(which is the majority of the directives)
-Much easier to hide/unhide a section in the macro directive history.
-Easier to track the effects of the directives across different submodules.
llvm-svn: 178037
|
|
|
|
|
|
|
|
|
| |
-Serialize the macro directives history into its own section
-Get rid of the macro updates section
-When de/serializing an identifier from a module, associate only one macro per
submodule that defined+exported it.
llvm-svn: 177761
|
|
|
|
|
|
|
|
| |
available the
full information about the macro (e.g if it was imported and where).
llvm-svn: 175978
|
|
|
|
|
|
|
|
| |
with more
arguments than it should accept.
llvm-svn: 175925
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroInfo class
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
llvm-svn: 175585
|
|
|
|
|
|
|
|
| |
#define X X
for which there is no point warning, ever.
llvm-svn: 173991
|
|
|
|
|
|
| |
This reverts commit r173952
llvm-svn: 173970
|
|
|
|
|
|
|
|
|
| |
for "#define X X".
This is a pattern that, for example, stdbool.h uses.
rdar://12435773
llvm-svn: 173952
|
|
|
|
|
|
|
|
|
|
|
|
| |
bogus with a PCH
that redefined a macro without undef'ing it first.
Proper reconstruction of the macro info history from modules will properly fix this in subsequent commits.
rdar://13016031
llvm-svn: 173281
|
|
|
|
| |
llvm-svn: 172884
|