If we are processing a #include from a module build, we should treat it
as a system header if we're building a system module. Passing an optional
flag to HeaderSearch::LookupFile.
Before this, the testing case will crash when accessing a freed FileEntry.
rdar://26214027
llvm-svn: 269730
getModuleContainingLocation ends up on the hot-path for typical C code
which can lead to calls to getFileIDSlow.
To speed this up, short circuit inferModuleFromLocation when there
aren't any modules, implicit or otherwise.
This shaves 4-5% build time when building the linux kernel.
llvm-svn: 269687
Clang performs directory walk while searching headers inside modules by
using the ::sys::fs instead of ::vfs. This prevents any code that uses
the VFS (e.g, reproducer scripts) to actually find such headers, since
the VFS will never be searched for those.
Change these places to use vfs::recursive_directory_iterator and
vfs::directory_iterator instead.
Differential Revision: http://reviews.llvm.org/D20266
rdar://problem/25880368
llvm-svn: 269661
(1) Collect headers under inner frameworks (frameworks inside other
other frameworks).
(2) Make sure we also collect the right header files inside them.
More info on (2):
Consider a dummy framework module B, with header Frameworks/B/B.h. Now
consider that another framework A, with header Frameworks/A/A.h, has a
layout with a inner framework Frameworks/A/Frameworks/B/B.h, where the
"B/B.h" part is a symlink for Frameworks/B/B.h. Also assume that
Frameworks/A/A.h includes <B/B.h>.
When parsing header Frameworks/A/A.h, framework module lookup is
performed in search for B, and it happens that
"Frameworks/A/Frameworks/B/B.h" path is registered in the module instead
of real "Frameworks/B/B.h". This occurs because
"Frameworks/A/Frameworks/B/B.h" is scanned first by the FileManager,
when looking for inner framework modules under Frameworks/A/Frameworks.
This makes Frameworks/A/Frameworks/B/B.h the default cached named inside
the FileManager for the B.h file UID.
This leads to modules being built without consistent paths to underlying
header files. This is usually not a problem in regular compilation flow,
but it's an issue when running the crash reproducer. The issue is that
clangs collect "Frameworks/A/Frameworks/B/B.h" but not
"Frameworks/B/B.h" into the VFS, leading to err_mmap_umbrella_clash. So
make sure we also collect the original header.
Differential Revision: http://reviews.llvm.org/D20194
rdar://problem/25880368
llvm-svn: 269502
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
Use a StringRef instead of a FileEntry in the moduleMapAddHeader
callback to allow more flexibility on what to collect on further
patches. This changes the interface I introduced in r264971.
llvm-svn: 268819
Summary:
Adds a framework to enable the instrumentation pass for the new
EfficiencySanitizer ("esan") family of tools. Adds a flag for esan's
cache fragmentation tool via -fsanitize=efficiency-cache-frag.
Adds appropriate tests for the new flag.
Reviewers: eugenis, vitalybuka, aizatsky, filcab
Subscribers: filcab, kubabrecka, llvm-commits, zhaoqin, kcc
Differential Revision: http://reviews.llvm.org/D19169
llvm-svn: 267059
xmmintrin.h a bit more directed. If for whatever reason modules are enabled but
we textually include one of these headers, don't deploy the special case for
modules. To make this work cleanly, extend __building_module to be defined
even when modules is disabled.
llvm-svn: 266945
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
and we fall back to textual inclusion, don't require the module as a whole to
be marked available; it's OK if some other file in the same module is missing,
just as it would be if the header were explicitly marked textual.
llvm-svn: 266113
Summary:
The parsing logic has been separated out from the macro implementation logic, leading to a number of improvements:
* Gracefully handle unexpected/invalid tokens, too few, too many and nested parameters
* Provide consistent behaviour between all built-in feature-like macros
* Simplify the implementation of macro logic
* Fix __is_identifier to correctly return '0' for non-identifiers
Reviewers: doug.gregor, rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D17149
llvm-svn: 265381
This allows plugins which add AST passes to also define pragmas to do things
like only enable certain behaviour of the AST pass in files where a certain
pragma is used.
Differential Revision: http://reviews.llvm.org/D18319
llvm-svn: 265295
This can happen as we look for '<<<<' while scanning tokens but then expect
'<<<<\n' to tell apart perforce from diff3 conflict markers. Just harden
the pointer arithmetic.
Found by libfuzzer + asan!
llvm-svn: 265125
The current ModuleDependencyCollector has a AST listener to collect
header files present in loaded modules, but this isn't enough to collect
all headers needed in the crash reproducer. One of the reasons is that
the AST writer doesn't write symbolic link header paths in the pcm modules,
this makes the listeners on the reader only able to collect the real files.
Since the module maps could contain submodules that use headers which
are symbolic links, not collecting those forbid the reproducer scripts
to regen the modules.
For instance:
usr/include/module.map:
...
module pthread {
header "pthread.h"
export *
module impl {
header "pthread_impl.h"
export *
}
}
...
usr/include/pthread/pthread_impl.h
usr/include/pthread_impl.h -> pthread/pthread_impl.h
The AST dump for the module above:
<SUBMODULE_HEADER abbrevid=6/> blob data = 'pthread_impl.h'
<SUBMODULE_TOPHEADER abbrevid=7/> blob data = '/<path_to_sdk>/usr/include/pthread/pthread_impl.h'
Note that we don't have "usr/include/pthread_impl.h" which is requested
by the module.map in case we want to reconstruct the module in the
reproducer. The reason the original symbolic link path isn't used is
because the headers are kept by name and requested through the
FileManager, which unique files and returns the real path only.
To fix that, add a callback to be invoked everytime a header is added
while parsing module maps and hook that up to the module dependecy
collector. This callback is only registered when generating the
reproducer.
Differential Revision: http://reviews.llvm.org/D18585
rdar://problem/24499339
llvm-svn: 264971
This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)).
This was commited in r263687 and reverted in 263752 due to misaligned
access.
rdar://20588929
llvm-svn: 263958
This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)). This enables the
compiler to provide Fix-Its for deprecated declarations.
rdar://20588929
llvm-svn: 263687
Since it's provided by the compiler. This allows a system module map
file to declare a module for it.
No test change for cstd.m, since stdatomic.h doesn't function without a
relatively complete stdint.h and stddef.h, which tests using this module
don't provide.
rdar://problem/24931246
llvm-svn: 263076
If the availability context is `FunctionTemplateDecl`, we should look
through it to the `FunctionDecl`. This prevents a diagnostic in the
following case:
class C __attribute__((unavailable));
template <class T> void foo(C&) __attribute__((unavailable));
This adds tests for availability in templates in many other cases, but
that was the only case that failed before this patch.
I added a feature `__has_feature(attribute_availability_in_templates)`
so users can test for this.
rdar://problem/24561029
llvm-svn: 262050
This reverts commit r261780. It turns out the original code was just
fine. An overload for ltrim which takes char was added but the Doxygen
docs haven't seemed to pick it up.
llvm-svn: 261784
Change getString() to return Optional<StringRef>, and change
lookupFilename() to return an empty string if either one of the prefix
and suffix can't be found.
This is a more robust follow-up to r261461, but it's still not entirely
satisfactory. Ideally we'd report that the header map is corrupt;
perhaps something for a follow-up.
llvm-svn: 261596
Switch to using `isPowerOf2_32()` to check whether the buckets are a
power of two, and as a side benefit reject loading a header map with no
buckets. This is a follow-up to r261448.
llvm-svn: 261585
If a header map file is corrupt, the strings in the string table may not
be null-terminated. The logic here previously relied on `MemoryBuffer`
always being null-terminated, but this isn't actually guaranteed by the
class AFAICT. Moreover, we're seeing a lot of crash traces at calls to
`strlen()` inside of `lookupFilename()`, so something is going wrong
there.
Instead, use `strnlen()` to get the length, and check for corruption.
Also remove code paths that could call `StringRef(nullptr)`. r261459
made these rather obvious (although they'd been there all along).
llvm-svn: 261461
This way it's easy to change HeaderMapImpl::getString() to return a
StringRef.
There's a slight change here, because I used `errs()` instead of
`dbgs()`. But `dbgs()` is more appropriate for a dump method.
llvm-svn: 261456
Check up front whether the header map buffer has space for all of its
declared buckets.
There was already a check in `getBucket()`, but it had UB (comparing
pointers that were outside of objects in the error path) and was
insufficient (only checking for a single byte of the relevant bucket).
I fixed the check, moved it to `checkHeader()`, and left a fixed version
behind as an assertion.
llvm-svn: 261449
If the number of buckets is not a power of two, immediately recognize
the header map as corrupt, rather than waiting for the first lookup. I
converted the later check to an assert.
llvm-svn: 261448
Split the implementation of `HeaderMap` into `HeaderMapImpl` so that we
can write unit tests that don't depend on the `FileManager`, and then
write a few tests that cover the types of corrupt header maps already
detected.
This also moves type and constant definitions from HeaderMap.cpp to
HeaderMapTypes.h so that the test can access them.
llvm-svn: 261446
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
llvm-svn: 261372
OpenCL Extension v1.2 s9.5 allows half precision floating point
type literals with suffices h or H when cl_khr_fp16 is enabled.
Example: half x = 1.0h;
Patch by Liu Yaxun (Sam)!
Differential Revision: http://reviews.llvm.org/D16865
llvm-svn: 261084
Manman Ren