context as anonymous for merging purposes. They can't be found by their names,
so we merge them based on their position within the surrounding context.
llvm-svn: 228485
This fixes PR21587, what r221933 fixed for regular programs is now also
fixed for decls coming from PCH files.
Use another bit from the count/bits uint16_t for storing the "more than one
decl" bit. This reduces the number of bits for the count from 14 to 13.
The selector with the most overloads in Cocoa.h has ~55 overloads, so 13 bits
should still be plenty. Since this changes the meaning of a serialized bit
pattern, also increase clang::serialization::VERSION_MAJOR.
Storing the "more than one decl" state of only the first overload isn't quite
correct, but Sema::AreMultipleMethodsInGlobalPool() currently only looks at
the state of the first overload so it's good enough for now.
llvm-svn: 224892
Remove ObjCMethodList::Count, instead store a "has more than one decl" bit in
the low bit of the ObjCMethodDecl pointer, using a PointerIntPair.
Most of this patch is replacing ".Method" with ".getMethod()".
No intended behavior change.
llvm-svn: 224876
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
llvm-svn: 224055
the root of the module and use paths relative to that directory wherever
possible. This is a step towards allowing explicit modules to be relocated
without being rebuilt, which is important for some kinds of distributed builds,
for good paths in diagnostics, and for appropriate .d output.
This is a recommit of r223443, reverted in r223465; when joining together
imported file paths, we now use the system's separator rather than always
using '/'. This avoids path mismatches between the original module build and
the module user on Windows (at least, in some cases). A more comprehensive
fix will follow.
llvm-svn: 223539
the root of the module and use paths relative to that directory wherever
possible. This is a step towards allowing explicit modules to be relocated
without being rebuilt, which is important for some kinds of distributed builds,
for good paths in diagnostics, and for appropriate .d output.
llvm-svn: 223443
rather than trying to extract this information from the FileEntry after the
fact.
This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.
llvm-svn: 223095
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>);
In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>);
Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info.
Differential Revision: http://reviews.llvm.org/D4002
llvm-svn: 221663
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.
No functionality change.
llvm-svn: 221558
Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs)
is not stable, it is not safe to load an AST file that depends on
another AST file that has been rebuilt since the importer was built,
even if "nothing changed". We previously used size and modtime to check
this, but I've seen cases where a module rebuilt quickly enough to foil
this check and caused very hard to debug build errors.
To save cycles when we're loading the AST, we just generate a random
nonce value and check that it hasn't changed when we load an imported
module, rather than actually hash the whole file.
This is slightly complicated by the fact that we need to verify the
signature inside addModule, since we might otherwise consider that a
mdoule is "OutOfDate" when really it is the importer that is out of
date. I didn't see any regressions in module load time after this
change.
llvm-svn: 220493
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
This is a better fix for 'duplicate key' problems in module continuous
range maps (vs what I added in r215810) by not adding any mappings at
all when there are no local entities. Now it also covers selectors,
which were not always being bumped because the record SELECTOR_OFFSET is
not always emitted. I'll back out most of r215810 in a future commit,
since it should no longer be needed.
llvm-svn: 220207
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
llvm-svn: 219900
We build a NestedNameSpecifier that records the CXXRecordDecl in which
__super appeared. Name lookup is performed in all base classes of the
recorded CXXRecordDecl. Use of __super is allowed only inside class and
member function scope.
llvm-svn: 218484
The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases --
that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls
wasn't used for anything before this warning it wasn't always set correctly,
so this patch also adds a few missing MarkAnyDeclReferenced() calls in
various places for TypedefNameDecls.
This is made a bit complicated due to local typedefs possibly being used only
after their local scope has closed. Consider:
template <class T>
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
Here the typedef in XXX is only used at end-of-translation unit, when YYY in
template_fun() gets instantiated. To handle this, typedefs that are unused when
their scope exits are added to a set of potentially unused typedefs, and that
set gets checked at end-of-TU. Typedefs that are still unused at that point then
get warned on. There's also serialization code for this set, so that the
warning works with precompiled headers and modules. For modules, the warning
is emitted when the module is built, for precompiled headers each time the
header gets used.
Finally, consider a function using C++14 auto return types to return a local
type defined in a header:
auto f() {
struct S { typedef int a; };
return S();
}
Here, the typedef escapes its local scope and could be used by only some
translation units including the header. To not warn on this, add a
RecursiveASTVisitor that marks all delcs on local types returned from auto
functions as referenced. (Except if it's a function with internal linkage, or
the decls are private and the local type has no friends -- in these cases, it
_is_ safe to warn.)
Several of the included testcases (most of the interesting ones) were provided
by Richard Smith.
(gcc's spelling -Wunused-local-typedefs is supported as an alias for this
warning.)
llvm-svn: 217298
tables that correspond to ContinuousRangeMaps, since the keys to those
maps need to be unique, or we may map to the wrong offset.
This fixes a crash + malformed AST file seen when loading some modules
that import Cocoa on Darwin, which is a module with no contents except
imports of other modules. Unfortunately I have not been able to find a
reduced test case that reproduces this problem.
Also add an assert that we aren't mapping one key to multiple values
in CRM. We ought to be able to say there are no duplicate keys at all,
but there are a bunch of 0 -> 0 mappings that are showing up, probably
coming from the source location table.
llvm-svn: 215810
definitions (because some other declaration declares a special member that
isn't present in the canonical definition), we need to search *all* of them; we
can't just stop when we find the requested name in any of the definitions,
because that can fail to find things (and in particular, it can fail to find
the member of the canonical declaration and return a bogus ODR failure).
llvm-svn: 215612
redefinitions of that namespace have already been loaded. When writing out the
names in a namespace, if we see a name that is locally declared and had
imported declarations merged on top of it, export the local declaration as the
lookup result, because it will be the most recent declaration of that entity in
the redeclaration chain of an importer of the module.
llvm-svn: 215518
We already verified the primary module map file (either the one that
defines the top-level module, or the one that allows inferring it if it
is an inferred framework module). Now we also verify any other module
map files that define submodules, such as when there is a
module.private.modulemap file.
llvm-svn: 215455
class Module. It's almost always going to be the same as
getContainingModule() for top-level modules, so just add a map to cover
the remaining cases. This lets us do less bookkeeping to keep the
ModuleMap fields up to date.
llvm-svn: 215268
also emit the updated 'operator delete' looked up for that destructor. Switch
from UpdateDecl to an actual update record when this happens due to implicitly
defining a special member function and unify this code path and the one for
instantiating a function definition.
llvm-svn: 215132
intent when we added remark support, but was never implemented in the general
case, because the first -R flags didn't need it. (-Rpass= had special handling
to accomodate its argument.)
-Rno-foo, -Reverything, and -Rno-everything can be used to turn off a remark,
or to turn on or off all remarks. Per discussion on cfe-commits, -Weverything
does not affect remarks, and -Reverything does not affect warnings or errors.
The only "real" -R flag we have right now is -Rmodule-build; that flag is
effectively renamed from -Wmodule-build to -Rmodule-build by this change.
-Wpass and -Wno-pass (and their friends) are also renamed to -Rpass and
-Rno-pass by this change; it's not completely clear whether we intended to have
a -Rpass (with no =pattern), but that is unchanged by this commit, other than
the flag name. The default pattern is effectively one which matches no passes.
In future, we may want to make the default pattern be .*, so that -Reverything
works for -Rpass properly.
llvm-svn: 215046
* Add abbreviation for CXXMethodDecl and for FunctionProtoType. These come up
a *lot* in C++ modules.
* Allow typedef declarations to use the abbreviation if they're class members,
or if they're used.
In passing, add more record name records for Clang AST node kinds.
The downside is that we had already used up our allotment of 12 abbreviations,
so this pushes us to an extra bit on each record to support the extra abbrev
kinds, which increases file size by ~1%. This patch *barely* pays for that
through the other improvements, but we've got room for another 18 abbrevs,
so we should be able to make it much more profitable with future changes.
llvm-svn: 214024
* Track override set across module load and save
* Track originating module to allow proper re-export of #undef
* Make override set properly transitive when it picks up a #undef
This fixes nearly all of the remaining macro issues with self-host.
llvm-svn: 213922
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
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 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
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
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
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 write little endian data to
an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
llvm-svn: 205044
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
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
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
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
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 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
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
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
Richard Smith