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
This reverts commit r211096. Looks like it broke the msvc build:
SemaOpenMP.cpp(140) : error C4519: default template arguments are only allowed on a class template
llvm-svn: 211113
This begins to address cognitive dissonance caused by treating the Note
diagnostic level as a severity in the diagnostic engine.
No change in functionality.
llvm-svn: 210758
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
This reapplies r209910 with a fix for the assertion failures hit on the
buildbots.
original commit message:
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.
So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.
Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.
<rdar://problem/17038180>
llvm-svn: 209922
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.
So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.
Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.
<rdar://problem/17038180>
llvm-svn: 209910
member functions), ensure that the redecl chain never transitions from 'inline'
to 'not inline', since that violates an AST invariant.
llvm-svn: 209794
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
instantiated in another module, and the instantiation uses a partial
specialization, include the partial specialization and its template arguments
in the update record. We'll need them if someone imports the second module and
tries to instantiate a member of the template.
llvm-svn: 209472
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
It appears that Windows doesn't like renaming over open files, which we
do in clearOutputFiles. The file being compiled should be safe to
removed, but this isn't very satisfying - we don't want to manually
manage the lifetime of files we cannot prove have no references.
llvm-svn: 209195
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
Follow-up fix for 209138. Actually, since we already have this file
open, we don't want to refresh the stat() info, since that might be
newer than what we have open (bad!).
llvm-svn: 209143
FileManager::invalidateCache is not safe to call when there may be
existing references to the file. What module load failure needs is
to refresh so stale stat() info isn't stored.
This may be the last user of invalidateCache; I'll take a look and
remove it if possible in a future commit.
This caused a use-after-free error as well as a spurious error message
that a module was "found in both 'X.pcm' and 'X.pcm'" in some cases.
llvm-svn: 209138
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
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
Summary:
Previously, we would generate a single name for all reference
temporaries and allow LLVM to rename them for us. Instead, number the
reference temporaries as we build them in Sema.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3554
llvm-svn: 207776
We need to open an ASTFile while checking its expected size and
modification time, or another clang instance can modify the file between
the stat() and the open().
llvm-svn: 207735
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
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
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
This paves the way to making OnDiskHashTable work with hashes that are
not 32 bits wide and to making OnDiskHashTable work very large hash
tables. The LLVM change to use these types is upcoming.
llvm-svn: 206640
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
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
Committed this by accident before it was done last time.
Original message:
Rather than rolling our own functions to write little endian data
to an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
llvm-svn: 205061
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
Rather than rolling our own functions to write little endian data to
an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
llvm-svn: 205044
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
an out-of-date external decls list). This happens if we declare some names,
force the lookup table for the decl context to be built, import a module that
adds more decls for the name, then write out our module without looking up the
name.
llvm-svn: 204694
specialization from a module. (This can also happen for function template
specializations in PCHs if they're instantiated eagerly, because they're
constexpr or have a deduced return type.)
llvm-svn: 204547
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
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
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
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
Drive-by fixing some incorrect types where a for loop would be improperly using ObjCInterfaceDecl::protocol_iterator. No functional changes in these cases.
llvm-svn: 203842
When building an AST file, we don't want to output HeaderFileInfo
structures for files that are not actually used as headers in the
current context. This can lead to assuming that unrelated files have
include counts of 0, defeating multiple-include prevention.
This is accomplished by adding an IsValid bit to the HFI.
llvm-svn: 203813
Add module dependencies to the dependency files created by -MD/-MMD/etc.
by attaching an ASTReaderListener that will call into the dependency
file generator when a module input file is seen in the serialized AST.
llvm-svn: 203208
submodule macro overriding within the same top-level module (necessary for the
testcase to be remotely reasonable). Incidentally reduces the number of libc++
testsuite regressions with modules enabled from 7 to 6.
llvm-svn: 203063
predicate. The wrapper used by SetVector was erroneously requiring an
adaptable predicate. It has been fixed and we really don't want to
require an indirect call for every predicate evaluation.
llvm-svn: 202744
it, importers of B should not see the macro. This is complicated by the fact
that A's macro could also be visible through a different path. The rules (as
hashed out on cfe-commits) are included as a documentation update in this
change.
With this, the number of regressions in libc++'s testsuite when modules are
enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are
due to remaining bugs in this change (in particular, the handling of submodules
is imperfect).
llvm-svn: 202560
This does;
- clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
- List of targets is added to LLVM_COMMON_DEPENDS.
- all clang libraries and targets depend on generated headers.
You might wonder this would be regression, but in fact, this is little loss.
- Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
- clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
- Each library's dependencies to tblgen'd files might vary along headers' structure.
It made hard to track and update *really optimal* dependencies.
Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.
llvm-svn: 201842
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
the build
When Clang loads the module, it verifies the user source files that the module
was built from. If any file was changed, the module is rebuilt. There are two
problems with this:
1. correctness: we don't verify system files (there are too many of them, and
stat'ing all of them would take a lot of time);
2. performance: the same module file is verified again and again during a
single build.
This change allows the build system to optimize source file verification. The
idea is based on the fact that while the project is being built, the source
files don't change. This allows us to verify the module only once during a
single build session. The build system passes a flag,
-fbuild-session-timestamp=, to inform Clang of the time when the build started.
The build system also requests to enable this feature by passing
-fmodules-validate-once-per-build-session. If these flags are not passed, the
behavior is not changed. When Clang verifies the module the first time, it
writes out a timestamp file. Then, when Clang loads the module the second
time, it finds a timestamp file, so it can compare the verification timestamp
of the module with the time when the build started. If the verification
timestamp is too old, the module is verified again, and the timestamp file is
updated.
llvm-svn: 201224
This triggered a miscompilation of code using Boost's function_template.hpp
when it was included inside a PCH file. A local static within
that header would be treated as local extern, resulting in the wrong
mangling. This only occurred during PCH deserialization.
Fixes <rdar://problem/15975816> and <rdar://problem/15926311>.
llvm-svn: 201130
We don't stat the system headers to check for stalenes during regular
PCH loading for performance reasons. When explicitly saying
-verify-pch, we want to check all the dependencies - user or system.
llvm-svn: 200979
This option will:
- load the given pch file
- verify it is not out of date by stat'ing dependencies, and
- return 0 on success and non-zero on error
llvm-svn: 200884
Add the ImportDecl to the set of interesting delcarations that are
deserialized eagerly when an AST file is loaded (rather than lazily like
most decls). This is required to get auto linking to work when there is
no explicit import in the main file. Also resolve a FIXME to rename
'ExternalDefinitions', since that is only one of the things that need eager
deserialization. The new name is 'EagerlyDeserializedDecls'. The corresponding
AST bitcode is also renamed.
llvm-svn: 200505
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
Show the top-level pch file as the culprit, rather than the immediate
dependency when a pch file imports a pcm from a module. To clarify the
relationship, the pch import stack is printed as notes. The old behaviour was
misleading when a pch imported a pcm (from a module), since removing the pcm
would not fix the problem, whereas rebuilding the pch would.
llvm-svn: 199446
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
llvm-svn: 199250
- Remove the additions to ObjCMethodDecl & ObjCIVarDecl that were getting de/serialized and consolidate
all functionality for the checking for this warning in Sema::DiagnoseUnusedBackingIvarInAccessor
- Don't check immediately after the method body is finished, check when the @implementation is finished.
This is so we can see if the ivar was referenced by any other method, even if the method was defined after the accessor.
- Don't silence the warning if any method is called from the accessor silence it if the accessor delegates to another method via self.
rdar://15727325
llvm-svn: 198432
Remove UnaryTypeTraitExpr and switch all remaining type trait related handling
over to TypeTraitExpr.
The UTT/BTT/TT enum prefix and evaluation code is retained pending further
cleanup.
This is part of the ongoing work to unify type traits following the removal of
BinaryTypeTraitExpr in r197273.
llvm-svn: 198271
This caused some crazy crashes involving std::unordered_map being
deserialized from a PCH file and then template instantiation requiring
an explicit instantiation location; unfortunately I don't really know
how to come up with a minimal test case.
llvm-svn: 197764
We started by trying to deserialize decltype(func-param) in a trailing return
type, which causes the function parameter decl to be deserialized, which pulls
in the function decl, which pulls the function type, which pulls the same
decltype() in the return type, and then we crashed.
llvm-svn: 197644
There's nothing special about type traits accepting two arguments.
This commit eliminates BinaryTypeTraitExpr and switches all related handling
over to TypeTraitExpr.
Also fixes a CodeGen failure with variadic type traits appearing in a
non-constant expression.
The BTT/TT prefix and evaluation code is retained as-is for now but will soon
be further cleaned up.
This is part of the ongoing work to unify type traits.
llvm-svn: 197273
more than one such initializer in a union, make mem-initializers override
default initializers for other union members, handle anonymous unions with
anonymous struct members better. Fix a couple of semi-related bugs exposed by
the tests for same.
llvm-svn: 196892
Summary:
In general, this type node can be used to represent any type adjustment
that occurs implicitly without losing type sugar. The immediate use of
this is to adjust the calling conventions of member function pointer
types without breaking template instantiation.
Fixes PR17996.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2332
llvm-svn: 196451
designated initializers of an interface.
If the interface declaration does not have methods marked as designated
initializers then the interface inherits the designated initializers of
its super class.
llvm-svn: 196315
This change fixes Richard's testcase for r193815. Now we include non-explicit
submodules into the list of exports.
The test failed previously because:
- recursive_visibility_a1.inner is not imported (only recursive_visibility_a1 is),
- thus the 'inner' submodule is not showing up in any of the import lists,
- and because of this getExportedModules() is not returning the
correct module set -- it only considers modules that are imported.
The fix is to make Module::getExportedModules() include non-explicit submodules
into the list of exports.
llvm-svn: 194018
would be deleted are still declared, but are ignored by overload resolution.
Also, don't delete such members if a subobject has no corresponding move
operation and a non-trivial copy. This causes us to implicitly declare move
operations in more cases, but risks move-assigning virtual bases multiple
times in some circumstances (a warning for that is to follow).
llvm-svn: 193969
requires ! feature
The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).
llvm-svn: 193549
A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test. The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html. Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box).
Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
No change in functionality.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Thanks!
llvm-svn: 193246
They were causing CodeGenCXX/mangle-exprs.cpp to fail.
Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl."
Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves."
llvm-svn: 193226
Both Doug and Richard had asked me to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
No change in functionality.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Thanks!
llvm-svn: 193223
modules.
With this fixed, I no longer see any test regressions in the libc++ test suite
when enabling a single-module module.map for libc++ (other than issues with my
system headers).
llvm-svn: 193219
* NamedDecl and CXXMethodDecl were missing getMostRecentDecl.
* The const version can just forward to the non const.
* getMostRecentDecl can use cast instead of cast_or_null.
This then removes some casts from the callers.
llvm-svn: 193039
If we have multiple definitions of the same entity from different modules, we
nominate the first definition which we see as being the canonical definition.
If we load a declaration from a different definition and we can't find a
corresponding declaration in the canonical definition, issue a diagnostic.
This is insufficient to prevent things from going horribly wrong in all cases
-- we might be in the middle of emitting IR for a function when we trigger some
deserialization and discover that it refers to an incoherent piece of the AST,
by which point it's probably too late to bail out -- but we'll at least produce
a diagnostic.
llvm-svn: 192950
Craig Topper