r260925 introduced a version of the *trim methods which is preferable
when trimming a single kind of character. Update all users in clang.
llvm-svn: 260927
While this won't help fix things like the bug that r260219 addressed, it
seems like good tidy up to have anyway.
(it might be nice if "makeArrayRef" always produced a MutableArrayRef &
let it decay to an ArrayRef when needed - then I'd use that for the
MutableArrayRefs in this patch)
If we had std::dynarray I'd use that instead of unique_ptr+size_t,
ideally (but then it'd have to be threaded down through the Preprocessor
all the way - no idea how painful that would be)
llvm-svn: 260246
This works around existing system headers which unconditionally
redefine these macros.
This is reasonably safe to do because we used to warn about it anyway
(outside of system headers). Continue to warn if the redefinition
would have changed the expansion. Still permit redefinition if the
macro is explicitly #undef'ed first.
rdar://23788307
llvm-svn: 255311
Summary:
If a module was unavailable (either a missing requirement on the module
being imported, or a missing file anywhere in the top-level module (and
not dominated by an unsatisfied `requires`)), we would silently treat
inclusions as textual. This would cause all manner of crazy and
confusing errors (and would also silently "work" sometimes, making the
problem difficult to track down).
I'm really not a fan of the `M->isAvailable(getLangOpts(), getTargetInfo(),
Requirement, MissingHeader)` function; it seems to do too many things at
once, but for now I've done things in a sort of awkward way.
The changes to test/Modules/Inputs/declare-use/module.map
were necessitated because the thing that was meant to be tested there
(introduced in r197805) was predicated on silently falling back to textual
inclusion, which we no longer do.
The changes to test/Modules/Inputs/macro-reexport/module.modulemap
are just an overlooked missing header that seems to have been missing since
this code was committed (r213922), which is now caught.
Reviewers: rsmith, benlangmuir, djasper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10423
llvm-svn: 245228
re-entering a modular header.
When we do the include guard check, we're in the visibility state for the file
with the #include; the include guard may not be visible there, but we don't
actually need it to be: if we've already parsed the submodule we're considering
entering, it's always safe to skip it.
llvm-svn: 241135
Introduce the clang pragmas "assume_nonnull begin" and "assume_nonnull
end" in which we make default assumptions about the nullability of many
unannotated pointers:
- Single-level pointers are inferred to __nonnull
- NSError** in a (function or method) parameter list is inferred to
NSError * __nullable * __nullable.
- CFErrorRef * in a (function or method) parameter list is inferred
to CFErrorRef __nullable * __nullable.
- Other multi-level pointers are never inferred to anything.
Implements rdar://problem/19191042.
llvm-svn: 240156
We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.
The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.
llvm-svn: 239789
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
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
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
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
#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
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
#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.
llvm-svn: 220177
According to the gcc docs, -include uses the current working directory
for the lookup instead of the main source file.
This patch gets rid of NormalizeIncludePath (which relied on an
implementation detail of FileManager / FileEntry for the include path
logic to work), and instead hands the correct lookup information down to
LookupFile.
This will allow us to change the FileEntry's behavior regarding its Name
caching.
llvm-svn: 215433
Clang :: Frontend/iframework.c
Clang :: Frontend/system-header-prefix.c
Clang :: Index/annotate-comments-objc.m
Clang :: Index/annotate-module.m
Clang :: Index/index-module.m
Clang :: Index/index-pch-with-module.m
Clang :: PCH/case-insensitive-include.c
Suprisingly the normalize_separators() was no-op when LLVM_ON_WIN32.
Its replacement native() does change path separators into \ as expected,
breaking these tests.
I had fixed the tests by #ifndef LLVM_ON_WIN32 on the native call,
to match the previous behaviour.
If this logic is not used on Windows host, it might be completely
deleted as there should not be windows path seperators on Linux hosts.
I can't test on Linux but if someone can run tests on Linux after
commenting out the line
llvm::sys::path::native(NormalizedPath);
and the tests pass, the whole if (LangOpts.MSVCCompat) could be deleted.
llvm-svn: 215290
* Track override set across module load and save
* Track originating module to allow proper re-export of #undef
* Make override set properly transitive when it picks up a #undef
This fixes nearly all of the remaining macro issues with self-host.
llvm-svn: 213922
Remove pointless MICache: it only ever contained up to 1 object, and was only
non-empty when recovering from an error. There's no performance or memory win
from maintaining this cache.
llvm-svn: 213825
This flag specifies that we are building an implementation file of the
module <name>, preventing importing <name> as a module. This does not
consider this to be the 'current module' for the purposes of doing
modular checks like decluse or non-modular-include warnings, unlike
-fmodule-name.
This is needed as a stopgap until:
1) we can resolve relative includes to a VFS-mapped module (or can
safely import a header textually and as part of a module)
and ideally
2) we can safely do incremental rebuilding when implementation files
import submodules.
llvm-svn: 213767
Vedant Kumar