| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
introduced by finalization. This is still not entirely correct; more fixes to
follow.
llvm-svn: 213498
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
thorough tests.
Original commit message:
[modules] Fix macro hiding bug exposed if:
* A submodule of module A is imported into module B
* Another submodule of module A that is not imported into B exports a macro
* Some submodule of module B also exports a definition of the macro, and
happens to be the first submodule of B that imports module A.
In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.
This happens with the 'assert' macro in an LLVM self-host. =(
llvm-svn: 213416
|
|
|
|
|
|
|
|
|
|
| |
This is breaking the system modules on Darwin, because something that
was defined and re-exported no longer is. Might be this patch, or might
just be a really poor interaction with an existing visibility bug.
This reverts commit r213348.
llvm-svn: 213395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* A submodule of module A is imported into module B
* Another submodule of module A that is not imported into B exports a macro
* Some submodule of module B also exports a definition of the macro, and
happens to be the first submodule of B that imports module A.
In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.
This happens with the 'assert' macro in an LLVM self-host. =(
llvm-svn: 213348
|
|
|
|
| |
llvm-svn: 212369
|
|
|
|
| |
llvm-svn: 211987
|
|
|
|
| |
llvm-svn: 211479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Successfully loaded module files may be referenced in other
ModuleManagers, so don't invalidate them. Two related things are fixed:
1) I thought the last module in the manager was always the one that
failed, but it isn't. So check explicitly against the list of
vetted modules from ReadASTCore.
2) We now keep the file descriptor of pcm file open, which avoids the
possibility of having two different pcms for the same module loaded when
building in parallel with headers being modified during a build.
<rdar://problem/16835846>
llvm-svn: 211330
|
|
|
|
|
|
|
| |
record, mark all subsequent decls as 'used' too, to maintain the AST invariant
that getPreviousDecl()->Used implies this->Used.
llvm-svn: 211050
|
|
|
|
| |
llvm-svn: 210802
|
|
|
|
|
|
|
|
|
|
|
|
| |
Diagnostic mappings are used to calculate the final severity of diagnostic
instances.
Detangle the implementation to reflect the terminology used in documentation
and bindings.
No change in functionality.
llvm-svn: 210518
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'optnone'.
This patch implements support for selectively disabling optimizations on a
range of function definitions through a pragma. The implementation is that
all function definitions in the range are decorated with attribute
'optnone'.
#pragma clang optimize off
// All function definitions in here are decorated with 'optnone'.
#pragma clang optimize on
// Compilation resumes as normal.
llvm-svn: 209510
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ASTReaderListener's documentation states that visitInputFile will be
called based on the return values of needsInputFileVisitation and
needsSystemInputFileVisitation, but ChainedASTReaderListener may call
these methods on a child listener based on the values returned by the
other child.
Even worse, the calls to visitInputFile may be short-circuited due to
the use of the boolean or, so the calls to visit may not occur at all
for the second listener.
This updates ChainedASTReaderListener::visitInputFile to propagate the
ASTReaderListener behaviour to both children.
llvm-svn: 209394
|
|
|
|
| |
llvm-svn: 209392
|
|
|
|
|
|
|
|
| |
declaration of that entity in from one of those modules, keep track of the fact
that we've not completed the redeclaration chain yet so that we can pull the
remaining declarations in from the other module if they're needed.
llvm-svn: 209161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
llvm-svn: 209046
|
|
|
|
|
|
| |
No change in functionality.
llvm-svn: 209005
|
|
|
|
|
|
|
|
| |
It makes more sense to just overload createFileID().
Gardening only.
llvm-svn: 209002
|
|
|
|
|
|
|
| |
Required pulling LambdaExpr::Capture into its own header.
No functionality change.
llvm-svn: 208470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use this to fix the leak of DeserializedDeclsDumper and DeserializedDeclsChecker
in FrontendAction (found by LSan), PR19560.
The "delete this" bool is necessary because both PCHGenerator and ASTUnit
return the same object from both getDeserializationListener() and
getASTMutationListener(), so ASTReader can't just have a unique_ptr.
It's also not possible to just let FrontendAction (or CompilerInstance) own
these listeners due to lifetime issues (see comments on PR19560).
Finally, ASTDeserializationListener can't easily be refcounted, since several of
the current listeners are allocated on the stack.
Having this bool isn't ideal, but it's a pattern that's used in other places in
the codebase too, and it seems better than leaking.
llvm-svn: 208277
|
|
|
|
|
|
| |
for the next time someone adds something to this function.
llvm-svn: 208270
|
|
|
|
|
|
| |
That's exactly what TinyPtrVector was designed for. No functionality change.
llvm-svn: 207919
|
|
|
|
|
|
|
| |
This fixes a bug where an update record causes us to load an entity that refers
to an entity we've not finished loading yet, resulting in badness.
llvm-svn: 207603
|
|
|
|
|
|
|
|
| |
driver only thing and doesn't affect any language/preprocessor/etc. semantics.
rdar://16714526
llvm-svn: 207570
|
|
|
|
|
|
|
|
| |
Fixed by moving ProcessWarningOptions from Frontend into Basic. All of
the dependencies for ProcessWarningOptions were already in Basic, so
this was a small change.
llvm-svn: 207549
|
|
|
|
|
|
| |
It tried to introduce cyclic dependencies. Serialization shouldn't depend on Frontend, since Frontend depends on Serialization.
llvm-svn: 207497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch checks whether the diagnostic options that could lead to
errors (principally -Werror) are consistent between when a module was
built and when it is loaded. If there are new -Werror flags, then the
module is rebuilt. In order to canonicalize the options we do this
check at the level of the constructed DiagnosticsEngine, which contains
the final set of diag to diagnostic level mappings. Currently we only
rebuild with the new diagnostic options, but we intend to refine this in
the future to include the union of the new and old flags, since we know
the old ones did not cause errors. System modules are only rebuilt when
-Wsystem-headers is enabled.
One oddity is that unlike checking language options, we don’t perform
this diagnostic option checking when loading from a precompiled header.
The reason for this is that the compiler cannot rebuild the PCH, so
anything that requires it to be rebuilt effectively leaks into the build
system. And in this case, that would mean the build system
understanding the complex relationship between diagnostic options and
the underlying diagnostic mappings, which is unreasonable. Skipping the
check is safe, because these options do not affect the generated AST.
You simply won’t get new build errors due to changed -Werror options
automatically, which is also true for non-module cases.
llvm-svn: 207477
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
together. This is extremely hairy, because in general we need to have loaded
both the template and the pattern before we can determine whether either should
be merged, so we temporarily violate the rule that all merging happens before
reading a decl ends, but *only* in the case where a template's pattern is being
loaded while loading the template itself.
In order to accomodate this for class templates, delay loading the injected
class name type for the pattern of the template until after we've loaded the
template itself, if we happen to load the template first.
llvm-svn: 207063
|
|
|
|
| |
llvm-svn: 207007
|
|
|
|
|
|
| |
imported from another module, emit an update record, rather than using the broken decl rewriting mechanism. If multiple modules do this, merge the definitions together, much as we would if they were separate declarations.
llvm-svn: 206680
|
|
|
|
| |
llvm-svn: 206217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To differentiate between two modules with the same name, we will
consider the path the module map file that they are defined by* part of
the ‘key’ for looking up the precompiled module (pcm file).
Specifically, this patch renames the precompiled module (pcm) files from
cache-path/<module hash>/Foo.pcm
to
cache-path/<module hash>/Foo-<hash of module map path>.pcm
In addition, I’ve taught the ASTReader to re-resolve the names of
imported modules during module loading so that if the header search
context changes between when a module was originally built and when it
is loaded we can rebuild it if necessary. For example, if module A
imports module B
first time:
clang -I /path/to/A -I /path/to/B ...
second time:
clang -I /path/to/A -I /different/path/to/B ...
will now rebuild A as expected.
* in the case of inferred modules, we use the module map file that
allowed the inference, not the __inferred_module.map file, since the
inferred file path is the same for every inferred module.
llvm-svn: 206201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the on disk hash table's key_iterator and data_iterator make
the assumption that the table data starts exactly four bytes after the
base of the table. This happens to be true for all of the tables we
currently iterate over, but not for all of the OnDiskHashTables we
currently use. For example, key_ and data_iterator would iterate over
meaningless data if they were used on the hash tables in PTHLexer.
We make the API safer by breaking this into two types. One doesn't
have the iterators, and the other must be told where the payload
starts.
llvm-svn: 206189
|
|
|
|
|
|
|
| |
With the VFS, it is easy to hit modified umbrellas by overriding the
umbrella header, and what we want is to rebuild, not to fail.
llvm-svn: 205975
|
|
|
|
|
|
| |
code-completion results.
llvm-svn: 205917
|
|
|
|
| |
llvm-svn: 205773
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Committed this by accident before it was done last time.
Original message:
Rather than rolling our own functions to read little endian data
from a buffer, we can use the support in llvm's Endian.h.
No functional change.
llvm-svn: 205062
|
|
|
|
|
|
| |
This reverts commit r205045.
llvm-svn: 205048
|
|
|
|
|
|
|
|
|
| |
Rather than rolling our own functions to read little endian data from
a buffer, we can use the support in llvm's Endian.h.
No functional change.
llvm-svn: 205045
|
|
|
|
| |
llvm-svn: 205021
|
|
|
|
|
|
|
|
|
| |
correctly order comments in SourceManager::isBeforeInTranslationUnit() order
Unfortunately, this is not as simple as it was implemented previously, and
actually requires doing a merge sort.
llvm-svn: 204936
|
|
|
|
| |
llvm-svn: 204550
|
|
|
|
|
|
| |
r204417 and related commits.
llvm-svn: 204471
|
|
|
|
|
|
|
| |
at which that PCH imported each visible submodule of the module. Such locations
are needed when synthesizing macro directives resulting from the import.
llvm-svn: 204417
|
|
|
|
|
|
| |
resolved, emit an update record.
llvm-svn: 204403
|
|
|
|
|
|
|
|
| |
block as decl and type emission. This allows decl updates include statements
and expressions. No functionality change (but the generated PCM files are
incompatible with earlier versions of Clang).
llvm-svn: 204385
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SubstTemplateTypeParmType
What's going on in the test case (without the patch applied) is this:
When the header is parsed, decltype(B()) is canonicalized to decltype(Y()),
because that was the first parsed equivalent decltype expression. Hence, the
TemplateSpecializationType for Id<decltype(B())> ends up with
SubstTemplateTypeParmType(T, decltype(Y())) as the AliasedType member.
When the PCH file is included and the AST reader reads Id<decltype(B())>, it
sees decltype(B()) before decltype(Y()). So, this time decltype(B()) ends up
being the canonical type for both decltypes, which leads to an assert violation
when the reader calls getSubstTemplateTypeParmType with the non-canonical
decltype(Y()) as the replacement type.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits, aemerson
Differential Revision: http://llvm-reviews.chandlerc.com/D3073
llvm-svn: 204005
|
|
|
|
| |
llvm-svn: 203951
|
|
|
|
|
|
|
|
|
|
|
| |
building one.
This is because the PCH is tied to the module files, if one of the module files changes or gets removed
the build system should re-build the PCH file.
rdar://16321245
llvm-svn: 203885
|
|
|
|
|
|
|
|
| |
doesn't show up as dependency of a module file.
Follow-up for rdar://15459210
llvm-svn: 203882
|