| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This reverts commit r298165, as it broke the ARM builds.
llvm-svn: 298185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands). Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly. Furthermore, the LockFileManager is not
robust in every environment. Other -cc1 commands can stall until
timeout (after about eight minutes).
This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack. The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module. Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout. Perhaps we should
reconsider blocking at all.
This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.
The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename. Its ownership is shared by the
CompilerInstance and ModuleManager.
- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.
- When modules fail to validate, they're removed from the cache.
- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.
- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.
Original patch by Manman Ren; most testcases by Adrian Prantl!
llvm-svn: 298165
|
|
|
|
| |
llvm-svn: 291202
|
|
|
|
| |
llvm-svn: 291160
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lexer sets the end location of macro arguments incorrectly *if*,
while merging consecutive args to fit into a single SLocEntry, it finds
args which come from different macro files.
Fix the issue by using separate SLocEntries in this situation.
This fixes a code coverage crasher (rdar://problem/26181005). Because
the lexer reported end locations for certain macro args incorrectly, we
would generate bogus coverage mappings with negative line offsets.
Reviewed-by: akyrtzi
Differential Revision: http://reviews.llvm.org/D20401
llvm-svn: 270160
|
|
|
|
|
|
|
|
| |
This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This
fixes the layering violation introduced earlier by threading CodeGenOptions into
TargetInfo. It should also fix the modules based self-hosting builds. NFC.
llvm-svn: 265702
|
|
|
|
|
|
|
|
|
| |
This threads CodeGenOptions into the TargetInfo hierarchy. This is motivated by
ARM which can change some target information based on the EABI selected
(-meabi). Similar options exist for other platforms (e.g. MIPS) and thus is
generally useful. NFC.
llvm-svn: 265640
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use it to calculate UserLabelPrefix, instead of specifying it (often
incorrectly).
Note that the *actual* user label prefix has always come from the
DataLayout, and is handled within LLVM. The main thing clang's
TargetInfo::UserLabelPrefix did was to set the #define value. Having
these be different from each-other is just silly.
Differential Revision: http://reviews.llvm.org/D17183
llvm-svn: 262737
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Add a simple test for `HeaderMap::lookupFileName()`. I'm planning to
add better error checking in a moment, and I'll add more tests like this
then.
llvm-svn: 261455
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
|
|
|
|
| |
llvm-svn: 249693
|
|
|
|
|
|
|
|
| |
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D11401
llvm-svn: 242931
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D8926
llvm-svn: 234678
|
|
|
|
|
|
|
| |
This is fragile, as there are classes with the same name in both
namespaces (e.g. llvm::Module and clang::Module).
llvm-svn: 219855
|
|
|
|
|
|
| |
Unique_ptr creation stil needs to be moved earlier at some of the call sites.
llvm-svn: 217474
|
|
|
|
| |
llvm-svn: 216715
|
|
|
|
| |
llvm-svn: 216585
|
|
|
|
| |
llvm-svn: 213853
|
|
|
|
| |
llvm-svn: 212388
|
|
|
|
| |
llvm-svn: 212369
|
|
|
|
| |
llvm-svn: 210423
|
|
|
|
|
|
|
|
|
|
|
|
| |
This corrects long-standing misuses of LLVM's internal config.h.
In most cases the public llvm-config.h header was intended and we can now
remove the old hacks thanks to LLVM r210144.
The config.h header is private, won't be installed and should no longer be
included by clang or other modules.
llvm-svn: 210145
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminate createMainFileID() / createMainFileIDForMemBuffer() utility
functions. These didn't add much convenience and conflated two distinct
operations.
This change makes things easier to follow by providing a consistent interface
and getting rid of a bunch of cast-to-voids.
llvm-svn: 209266
|
|
|
|
|
|
|
| |
Required pulling LambdaExpr::Capture into its own header.
No functionality change.
llvm-svn: 208470
|
|
|
|
|
|
|
|
|
| |
Having various possible states of initialization following construction doesn't
add value here.
Also remove the unused size_reserve parameter.
llvm-svn: 207897
|
|
|
|
|
|
| |
Landing this separately to make the previous commits easy to follow at home.
llvm-svn: 207826
|
|
|
|
|
|
|
|
| |
The Preprocessor::Initialize() function already offers a clear interface to
achieve this, further reducing the confusing number of states a newly
constructed preprocessor can have.
llvm-svn: 207825
|
|
|
|
| |
llvm-svn: 207011
|
|
|
|
|
|
| |
symbols in non-imported modules.
llvm-svn: 206977
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
CMakeLists.txt.
llvm-svn: 196916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows using virtual file mappings on the original SourceManager to
map in virtual module.map files. Without this patch, the ModuleMap
search will find a module.map file (as the FileEntry exists in the
FileManager), but will be unable to get the content from the
SourceManager (as ModuleMap previously created its own SourceManager).
Two problems needed to be fixed which this patch exposed:
1. Storing the inferred module map
When writing out a module, the ASTWriter stores the names of the files
in the main source manager; when loading the AST again, the ASTReader
errs out if such a file is found missing, unless it is overridden.
Previously CompilerInstance's compileModule method would store the
inferred module map to a temporary file; the problem with this approach
is that now that the module map is handled by the main source manager,
the ASTWriter stores the name of the temporary module map as source to
the compilation; later, when the module is loaded, the temporary file
has already been deleted, which leads to a compilation error. This patch
changes the inferred module map to instead inject a virtual file into
the source manager. This both saves some disk IO, and works with how the
ASTWriter/ASTReader handle overridden source files.
2. Changing test input in test/Modules/Inputs/*
Now that the module map file is handled by the main source manager, the
VerifyDiagnosticConsumer will not ignore diagnostics created while
parsing the module map file. The module test test/Modules/renamed.m uses
-I test/Modules/Inputs and triggers recursive loading of all module maps
in test/Modules/Inputs, some of which had conflicting names, thus
leading errors while parsing the module maps. Those diagnostics already
occur on trunk, but before this patch they would not break the test, as
they were ignored by the VerifyDiagnosticConsumer. This patch thus
changes the module maps that have been recently introduced which broke
the invariant of compatible modules maps in test/Modules/Inputs.
llvm-svn: 193314
|
|
|
|
| |
llvm-svn: 192572
|
|
|
|
|
|
| |
Patch from Rami Ylimäki and Mikael Lepistö!
llvm-svn: 192531
|
|
|
|
|
|
| |
I am about to move PathV2.h to Path.h.
llvm-svn: 183795
|
|
|
|
|
|
|
|
| |
function macro arguments.
This is a modified version of a patch by Manuel Klimek.
llvm-svn: 182055
|
|
|
|
|
|
| |
and warn when a newly-imported module conflicts with an already-imported module.
llvm-svn: 177577
|
|
|
|
|
|
| |
module import occurred.
llvm-svn: 174191
|
|
|
|
| |
llvm-svn: 173409
|
|
|
|
| |
llvm-svn: 172295
|
|
|
|
|
|
| |
I forgot to re-sort after fixing main module headers.
llvm-svn: 169244
|