"1-4" specifiers are returned as numeric constants, not identifiers,
and should be treated as such. Currently pragma handler incorrectly
assumes that they are returned as identifiers.
Patch by Andrey Bokhanko.
Differential Revision: http://reviews.llvm.org/D9856
llvm-svn: 238129
visibility is enabled) or leave and re-enter it, restore the macro and module
visibility state from last time we were in that submodule.
This allows mutually-#including header files to stand a chance at being
modularized with local visibility enabled.
llvm-svn: 237871
glibc's headers use __need_* macros to selectively export parts of themselves
to each other. This requires us to enter those files repeatedly when building
a glibc module.
This can be unreverted once we have a better mechanism to deal with that
non-modular aspect of glibc (possibly some way to mark a header as "textual if
this macro is defined").
llvm-svn: 237718
enter it more than once, even if it doesn't have #include guards -- we already
know that it is intended to have the same effect every time it's included, and
it's already had that effect. This particularly helps with local submodule
visibility builds, where the include guard macro may not be visible in the
includer, but will become visible the moment we enter the included file.
llvm-svn: 237609
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
llvm-svn: 237473
This, in preparation for the introduction of more new keywords in the
implementation of the C++ language, generalizes the support for future keyword
compat diagnostics (e.g., diag::warn_cxx11_keyword) by extending the
applicability of the relevant property in IdentifierTable with appropriate
renaming.
Patch by Hubert Tong!
llvm-svn: 237332
Summary:
Fix PR22407, where the Lexer overflows the buffer when parsing
#include<\
(end of file after slash)
Test Plan:
Added a test that will trigger in asan build.
This case is also covered by the clang-fuzzer bot.
Reviewers: rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9489
llvm-svn: 236466
clang::MacroDefinition now models the currently-defined value of a macro. The
previous MacroDefinition type, which represented a record of a macro definition
directive for a detailed preprocessing record, is now called MacroDefinitionRecord.
llvm-svn: 236400
This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module). Thus names
will only be visible if a header / module that declares them has actually been
included / imported, and not merely because a submodule that happened to be
built earlier declared those names. This also removes the need to modularize
bottom-up: textually-included headers will be included into every submodule
that includes them, since their include guards will not leak between modules.
So far, this only governs visibility of macros, not of declarations, so is not
ready for real use yet.
llvm-svn: 236350
It has no place there; it's not a property of the Module, and it makes
restoring the visibility set when we leave a submodule more difficult.
llvm-svn: 236300
Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definition information
faithfully: we have a linear macro directive history within each module, and at
any point we have a unique "latest" local macro directive and a collection of
visible imported directives. This also removes the attendent complexity of
attempting to create a correct MacroDirective history (which we got wrong
in the general case).
No functionality change intended.
llvm-svn: 236176
the active module macros at the point of definition, rather than reconstructing
it from the macro history. No functionality change intended.
llvm-svn: 235941
Previously we'd defer this determination until writing the AST, which doesn't
allow us to use this information when building other submodules of the same
module. This change also allows us to use a uniform mechanism for writing
module macro records, independent of whether they are local or imported.
llvm-svn: 235614
This graph will be used to determine the current set of active macros. This is
foundation work for getting macro visibility correct across submodules of the
current module. No functionality change for now.
llvm-svn: 235461
In public MS headers for XAudio, clang would fail to generate a valid UUID due to the UUID components being combined with the '-' UUID separators. Clang would attempting to recover but would preserve the leading whitespace from the tokens after each failed paste leading to spaces creeping into the UUID and causing an error in the __declspace(uuid()) parsing.
Reference: Microsoft DirectX SDK (June 2010)\Include\XAudio2.h(51)
Resolves http://llvm.org/pr23071
llvm-svn: 235186
Writing 4k of zeros is preferrable to 4k of random memory. Document that. While
there remove the initialization of the first byte of the buffer and start at
index zero. It was writing a literal '0' instead of a null byte at the
beginning anyways, which didn't matter since we never read it.
llvm-svn: 234202
ExpandBuiltinMacro would strip the identifier and downstream users crash
when they encounter an identifier token with nullptr identifier info.
Found by afl-fuzz.
llvm-svn: 233497
While dereferencing ThisTokEnd is fine and we know that it's not in
[a-zA-Z0-9_.], ThisTokEnd[1] is really past the end.
Found by asan and with a little help from clang-fuzz.
llvm-svn: 233491
Simplify boolean expressions using `true` and `false` with `clang-tidy`
Patch by Richard Thomson.
Differential Revision: http://reviews.llvm.org/D8531
llvm-svn: 232999
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
These calls are usually guarded by checks for isAnnotation() but it
looks like we missed a spot. This would cause the included test to
crash clang.
llvm-svn: 232616
This basically creates a wrapper around an 'int' that poses as an iterator.
While that looks a bit counter-intuitive it works just fine because iterator
operations and basic integer arithmetic works in exactly the same way.
Remove the manual integer wrapping code and reduce the reliance on iterator
internals in the implementation. No functionality change intended.
llvm-svn: 232322
check that private headers are in a list matching the role. (We can't perform
the opposite checks for non-private headers because we infer those.)
llvm-svn: 231728
This adds the -fapplication-extension option, along with the
ios_app_extension and macosx_app_extension availability attributes.
Patch by Ted Kremenek
llvm-svn: 230989
This would cause frameworks to have spurious "redefinition" errors if
they had both a (legacy) "module.map" and a (new) "module.modulemap" file and we
happened to do a sub-directory search in that directory using a
non-framework include path (e.g. -Ifoo/ -Ffoo/). For migration
purposes it's very handy that the compiler will prefer the new spelling
of the filename and not look at the old one if it doesn't need to.
llvm-svn: 230308
When mangling the module map path into a .pcm file name, also mangle the
IsSystem bit, which can also depend on the header search paths. For
example, the user may change from -I to -isystem. This can affect
diagnostics in the importing TU.
llvm-svn: 228966
If a module map contains
framework module * [extern_c] {}
We will now infer [extern_c] on the inferred framework modules (we
already inferred [system] as a special case).
llvm-svn: 225803
We'd let annotation tokens from '#pragma pack' and the like get inside a
function-like macro. This would lead to terror and mayhem; stop the
madness early.
This fixes PR22037.
llvm-svn: 224896
Repared support for warnings -Wkeyword-macro and -Wreserved-id-macro.
The warning -Wkeyword-macro now is not issued in patterns that are used
in configuration scripts:
#define inline
also for 'const', 'extern' and 'static'. If macro repalcement is identical
to macro name, the warning also is not issued:
#define volatile volatile
And finally if macro replacement is also a keyword identical to the replaced
one but decorated with leading/trailing underscores:
#define inline __inline
#define inline __inline__
#define inline _inline // in MSVC compatibility mode
Warning -Wreserved-id-macro is off by default, it could help catching
things like:
#undef __cplusplus
llvm-svn: 224512
As discussed on the post-commit review thread for r224012, -Wkeyword-macro fires
mostly on headers trying to set up portable defines and doesn't find much bad
stuff in practice. But [macro.names]p2 does disallow defining or undefining
keywords, override and final, and alignas, so keep the warning but move it
into -pedantic.
-Wreserved-id-macro warns on
#define __need_size_t
which is more or less public api for glibc headers. Since this warning isn't
motivated by a standard, remove it.
(See also r223114 for a previous follow-up to r224012.)
llvm-svn: 224371
We would CreateString on arbitrary garbage instead of just skipping to
the end of the builtin macro. Eventually, this would cause us to crash
because we would end up replacing the contents of a character token with
a numeric literal.
This fixes PR21825.
llvm-svn: 224238
Clang should form a wide string literal from L#macro_arg in a function-like macro in -fms-compatibility mode.
Fix for http://llvm.org/PR9984.
Differential Revision: http://reviews.llvm.org/D6604
llvm-svn: 224228
We would check if the terminator marker is on a newline. However, the
logic would end up out-of-bounds if the terminator marker immediately
follows the start marker.
This fixes PR21820.
llvm-svn: 224210
#undef a keyword is generally harmless but used often in configuration scripts.
Also added tests that I forgot to include to commit in r223114.
llvm-svn: 224100
This means that a pointer to the struct type to which the attribute appertains
is a CF type (and therefore an Objective-C object of some type), but not of any
specific class. rdar://19157264
llvm-svn: 224072
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
llvm-svn: 224055
Original commit message:
[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223913
in debugger mode) to accept @import declarations
and pass them to the debugger.
In the preprocessor, accept import declarations
if the debugger is enabled, but don't actually
load the module, just pass the import path on to
the preprocessor callbacks.
In the Objective-C parser, if it sees an import
declaration in statement context (usual for LLDB),
ignore it and return a NullStmt.
llvm-svn: 223855
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223753
Summary:
This change implements warnings if macro name is identical to a keyword or
reserved identifier. The warnings are different depending on the "danger"
of the operation. Defining macro that replaces a keyword is on by default.
Other cases produce warning that is off by default but can be turned on
using option -Wreserved-id-macro.
This change fixes PR11488.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D6194
llvm-svn: 223114
rather than trying to extract this information from the FileEntry after the
fact.
This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.
llvm-svn: 223095
Alexander Musman