| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(dropping const from the reference as MemoryBuffer is immutable already,
so const is just redundant - and while I'd personally put const
everywhere, that's not the LLVM Way (see llvm::Type for another example
of an immutable type where "const" is omitted for brevity))
Changing the pointer argument to a reference parameter makes call sites
identical between callers with unique_ptrs or raw pointers, minimizing
the churn in a pending unique_ptr migrations.
llvm-svn: 215391
|
|
|
|
|
|
|
|
| |
After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownership semantics explicit in
the source using the type system.
llvm-svn: 215323
|
|
|
|
| |
llvm-svn: 215321
|
|
|
|
| |
llvm-svn: 215320
|
|
|
|
| |
llvm-svn: 215317
|
|
|
|
|
|
|
|
|
| |
This reverts commit r213307.
Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.
llvm-svn: 213325
|
|
|
|
|
|
|
|
|
| |
(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follows the source back to its origin pushing unique_ptr
ownership up through there too)
llvm-svn: 213307
|
|
|
|
|
|
| |
The facility was abstracted to LLVM in r187364.
llvm-svn: 212441
|
|
|
|
| |
llvm-svn: 212438
|
|
|
|
| |
llvm-svn: 212388
|
|
|
|
|
|
|
| |
This type is only refcounted in a couple of places so making ownership explicit
improves clarity.
llvm-svn: 212387
|
|
|
|
|
|
|
| |
This makes it clear that TargetInfo doesn't capture the LangOptions object,
rather uses it to apply adjustments.
llvm-svn: 212386
|
|
|
|
| |
llvm-svn: 212369
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add module dependencies (header files, module map files) to the list of
files to check when deciding whether to rebuild a preamble. That fixes
using preambles with module imports so long as they are in
non-overridden files.
My intent is to use to unify the existing dependency collectors to the
new “DependencyCollectory” interface from this commit, starting with the
DependencyFileGenerator.
llvm-svn: 212060
|
|
|
|
|
|
|
|
|
|
| |
We were using old stat values for any files that had previously been
looked up, leading to badness. There might be a more elegant solution in
invalidating the cache for those file (since we already know which ones
they are), but it seems too likely there are existing references to
them hiding somewhere.
llvm-svn: 211504
|
|
|
|
| |
llvm-svn: 209389
|
|
|
|
|
|
|
|
|
| |
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: 207427
|
|
|
|
| |
llvm-svn: 207237
|
|
|
|
|
|
|
|
|
| |
We don't need the ASTContext for the diagnostics, only the language
options, which we can get from the compiler invocation. It worries me
how many categorically different states the ASTUnit class can be in
depending on how it is being constructed/used.
llvm-svn: 206909
|
|
|
|
|
|
|
| |
When transferring data from a CompilerInstance in an error path we need
to consider cases where the various fields are uninitialized.
llvm-svn: 206644
|
|
|
|
|
|
|
| |
This allows code indexing, etc. to use the VFS in the same way as the
compiler.
llvm-svn: 206309
|
|
|
|
|
|
| |
class.
llvm-svn: 203758
|
|
|
|
|
|
|
|
|
| |
Padding does not seem to be useful currently, and it leads to bogus location if an error
points to the end of the file.
rdar://15836513
llvm-svn: 203370
|
|
|
|
|
|
| |
with iterator_range enumerators(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203353
|
|
|
|
|
|
| |
This compiles cleanly with lldb/lld/clang-tools-extra/llvm.
llvm-svn: 203279
|
|
|
|
|
|
| |
iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203278
|
|
|
|
|
|
| |
This is a precursor to moving to std::unique_ptr.
llvm-svn: 203275
|
|
|
|
|
|
| |
No intended functionality change.
llvm-svn: 202652
|
|
|
|
| |
llvm-svn: 202639
|
|
|
|
|
|
|
|
|
|
| |
that created them,
this is inherently unsafe.
Instead get the diagnostic info into a SourceManager-independent form.
llvm-svn: 202471
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ASTUnit::getMainBufferWithPrecompiledPreamble().
With r197755 we started reading the contents of buffer file entries, but the
buffers may point to ASTReader blobs that have been disposed.
Fix this by having the CompilerInstance object keep a reference to the ASTReader
as well as having the ASTContext keep reference to the ExternalASTSource.
This was very difficult to construct a test case for.
rdar://16149782
llvm-svn: 202346
|
|
|
|
|
|
|
|
|
|
|
| |
Previously reverted in r201755 due to causing an assertion failure.
I've removed the offending assertion, and taught the CompilerInstance to
create a default virtual file system inside createFileManager. In the
future, we should be able to reach into the CompilerInvocation to
customize this behaviour without breaking clients that don't care.
llvm-svn: 201818
|
|
|
|
|
|
|
|
|
|
| |
assertion
in our internal build bots.
This reverts commits 201618, 201635, 201636, 201639, 201685, 201691, and 201696.
llvm-svn: 201755
|
|
|
|
| |
llvm-svn: 201739
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the minimum virtual file system support to start migrating
FileManager onto the VFS.
Originally discussed here:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-February/035188.html
Differential Revision: http://llvm-reviews.chandlerc.com/D2745
llvm-svn: 201618
|
|
|
|
| |
llvm-svn: 201220
|
|
|
|
| |
llvm-svn: 201082
|
|
|
|
|
|
|
| |
ASTUnit contains code to remap files to other files on disk. This code is not
used. We only remap files to MemoryBuffers.
llvm-svn: 201010
|
|
|
|
| |
llvm-svn: 200975
|
|
|
|
|
|
|
|
|
|
| |
llvm::sys::cas_flag is 'long' instead of 'uint32_t' on win32, because
that's what InterlockedIncrement is defined to accept.
I still don't know if we should be calling fprintf from ASTUnit.cpp
behind a getenv check.
llvm-svn: 200718
|
|
|
|
| |
llvm-svn: 198957
|
|
|
|
|
|
|
| |
The MD5 is checked since r197755 which is as good as comparing buffer contents
in this context.
llvm-svn: 197842
|
|
|
|
| |
llvm-svn: 197762
|
|
|
|
|
|
|
|
|
|
|
| |
files to tell if they were changed since the last time we have computed the
preamble
We used to check only the buffer size, so if the new remapped buffer has the
same size as the previous one, we would think that the buffer did not change,
and we did not rebuild the preambule, which sometimes caused us to crash.
llvm-svn: 197755
|
|
|
|
| |
llvm-svn: 197748
|
|
|
|
|
|
|
|
|
| |
ASTUnit instances are allocated infrequently so it's fine to keep this field
around in all build configurations.
Assigns null to silence -Wunused-private-field in Release.
llvm-svn: 195419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|