This patch improves traceability of duplicated header files which end
up in multiple pcms.
Differential Revision: https://reviews.llvm.org/D47118
llvm-svn: 337353
Summary:
Reproducer and errors:
https://bugs.llvm.org/show_bug.cgi?id=37878
lookupModule was falling back to loadSubdirectoryModuleMaps when it couldn't
find ModuleName in (proper) search paths. This was causing iteration over all
files in the search path subdirectories for example "/usr/include/foobar" in
bugzilla case.
Users don't expect Clang to load modulemaps in subdirectories implicitly, and
also the disk access is not cheap.
if (AllowExtraModuleMapSearch) true with ObjC with @import ModuleName.
Reviewers: rsmith, aprantl, bruno
Subscribers: cfe-commits, teemperor, v.g.vassilev
Differential Revision: https://reviews.llvm.org/D48367
llvm-svn: 336660
Functions that are a sub-Decl of a record were hashed differently than other
functions. This change keeps the AddFunctionDecl function and the hash of
records now calls this function. In addition, AddFunctionDecl has an option
to perform a hash as if the body was absent, which is required for some
checks after loading modules. Additional logic prevents multiple error
message from being printed.
llvm-svn: 336632
merged function definitions; also merge functions with deduced return
types.
This seems like two independent fixes, but unfortunately they are hard
to separate because it's challenging to reliably test either one of them
without also testing the other.
A complication arises with deduced return type support: we need the type
of the function in order to know how to merge it, but we can't load the
actual type of the function because it might reference an entity
declared within the function (and we need to have already merged the
function to correctly merge that entity, which we would need to do to
determine if the function types match). So we instead compare the
declared function type when merging functions, and defer loading the
actual type of a function with a deduced type until we've finished
loading and merging the function.
This reverts r336175, reinstating r336021, with one change (for PR38015):
we look at the TypeSourceInfo of the first-so-far declaration of each
function when considering whether to merge two functions. This works
around a problem where the calling convention in the TypeSourceInfo for
subsequent redeclarations may not match if it was implicitly adjusted.
llvm-svn: 336240
This caused test failures in 32-bit builds (PR38015).
> merged function definitions; also merge functions with deduced return
> types.
>
> This seems like two independent fixes, but unfortunately they are hard
> to separate because it's challenging to reliably test either one of them
> without also testing the other.
>
> A complication arises with deduced return type support: we need the type
> of the function in order to know how to merge it, but we can't load the
> actual type of the function because it might reference an entity
> declared within the function (and we need to have already merged the
> function to correctly merge that entity, which we would need to do to
> determine if the function types match). So we instead compare the
> declared function type when merging functions, and defer loading the
> actual type of a function with a deduced type until we've finished
> loading and merging the function.
llvm-svn: 336175
Not doing so causes the AST writter to assert since the decl in question
never gets emitted. This is fine when modules is not used, but otherwise
we need to serialize something other than garbage.
rdar://problem/39844933
Differential Revision: https://reviews.llvm.org/D47297
llvm-svn: 336031
merged function definitions; also merge functions with deduced return
types.
This seems like two independent fixes, but unfortunately they are hard
to separate because it's challenging to reliably test either one of them
without also testing the other.
A complication arises with deduced return type support: we need the type
of the function in order to know how to merge it, but we can't load the
actual type of the function because it might reference an entity
declared within the function (and we need to have already merged the
function to correctly merge that entity, which we would need to do to
determine if the function types match). So we instead compare the
declared function type when merging functions, and defer loading the
actual type of a function with a deduced type until we've finished
loading and merging the function.
llvm-svn: 336021
ODRHash aims to provide Cross-TU stable hashing. Making clang::Type pointer
part of the hash connects (remotely) the ODRHash with the TU-specific
::Profile hasher.
r332281 exposed the issue by changing the way the ASTContext different
elaborated types if there is an owning tag. In that case, ODRHash stores two
different types in its TypeMap which yields false ODR violation in modules.
The current state of implementation shouldn't need the TypeMap concept
anymore. Rip it out.
Differential Revision: https://reviews.llvm.org/D48524
llvm-svn: 335853
checks across module boundaries. This was causing us to load constructor
definitions for all consumers of a module with a pending check.
(In one case we saw ~7% of total frontend time spent loading
constructors for this check.)
llvm-svn: 335807
declaration of the function that ends up in the primary definition of
the class.
... at least for class templates. This is necessary for us to be able to
track when an inline friend function has a definition that needs to be
(lazily) instantiated.
llvm-svn: 335805
Using @import in framework headers inhibit the use of such headers
when not using modules, this is specially bad for headers that end
up in the SDK (or any other system framework). Add a warning to give
users some indication that this is discouraged.
rdar://problem/39192894
llvm-svn: 335780
Framework vendors usually layout their framework headers in the
following way:
Foo.framework/Headers -> "public" headers
Foo.framework/PrivateHeader -> "private" headers
Since both headers in both directories can be found with #import
<Foo/some-header.h>, it's easy to make mistakes and include headers in
Foo.framework/PrivateHeader from headers in Foo.framework/Headers, which
usually configures a layering violation on Darwin ecosystems. One of the
problem this causes is dep cycles when modules are used, since it's very
common for "private" modules to include from the "public" ones; adding
an edge the other way around will trigger cycles.
Add a warning to catch those cases such that:
./A.framework/Headers/A.h:1:10: warning: public framework header includes private framework header 'A/APriv.h'
#include <A/APriv.h>
^
rdar://problem/38712182
llvm-svn: 335542
Introduce -Wquoted-include-in-framework-header, which should fire a warning
whenever a quote include appears in a framework header and suggest a fix-it.
For instance, for header A.h added in the tests, this is how the warning looks
like:
./A.framework/Headers/A.h:2:10: warning: double-quoted include "A0.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header]
#include "A0.h"
^~~~~~
<A/A0.h>
./A.framework/Headers/A.h:3:10: warning: double-quoted include "B.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header]
#include "B.h"
^~~~~
<B.h>
This helps users to prevent frameworks from using local headers when in fact
they should be targetting system level ones.
The warning is off by default.
Differential Revision: https://reviews.llvm.org/D47157
rdar://problem/37077034
llvm-svn: 335375
Header maps are binary files used by Xcode, which are used to map
header names or paths to other locations. Clang has support for
those since its inception, but there's not a lot of header map
testing around.
Since it's a binary format, testing becomes pretty much brittle
and its hard to even know what's inside if you don't have the
appropriate tools.
Add a python based tool that allows creating and dumping header
maps based on a json description of those. While here, rewrite
tests to use the tool and remove the binary files from the tree.
This tool was initially written by Daniel Dunbar.
Thanks to Stella Stamenova for helping make this work on Windows.
Differential Revision: https://reviews.llvm.org/D46485
rdar://problem/39994722
llvm-svn: 335295
Introduce -Wquoted-include-in-framework-header, which should fire a warning
whenever a quote include appears in a framework header and suggest a fix-it.
For instance, for header A.h added in the tests, this is how the warning looks
like:
./A.framework/Headers/A.h:2:10: warning: double-quoted include "A0.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header]
#include "A0.h"
^~~~~~
<A/A0.h>
./A.framework/Headers/A.h:3:10: warning: double-quoted include "B.h" in framework header, expected angle-bracketed instead [-Wquoted-include-in-framework-header]
#include "B.h"
^~~~~
<B.h>
This helps users to prevent frameworks from using local headers when in fact
they should be targetting system level ones.
The warning is off by default.
Differential Revision: https://reviews.llvm.org/D47157
rdar://problem/37077034
llvm-svn: 335184
Header maps are binary files used by Xcode, which are used to map
header names or paths to other locations. Clang has support for
those since its inception, but there's not a lot of header map
testing around.
Since it's a binary format, testing becomes pretty much brittle
and its hard to even know what's inside if you don't have the
appropriate tools.
Add a python based tool that allows creating and dumping header
maps based on a json description of those. While here, rewrite
tests to use the tool and remove the binary files from the tree.
This tool was initially written by Daniel Dunbar.
Differential Revision: https://reviews.llvm.org/D46485
rdar://problem/39994722
llvm-svn: 335177
When in the context of suggestion the fix-it from .Private to _Private
for private modules, trim off the 'explicit' and add 'framework' when
appropriate.
rdar://problem/41030554
llvm-svn: 334859
Previous, if no Decl's were checked, visibility was set to false. Switch it
so that in cases of no Decl's, return true. These are the Decl's after being
filtered. Also remove an unreachable return statement since it is directly
after another return statement.
llvm-svn: 334160
Avoid storing information for definitions since those can be out-of-line and
vary between modules even when the declarations are the same.
llvm-svn: 334151
When a module declaration for a framework lacks the 'framework'
qualifier, the listed headers aren't found (because there's no
trigger for the special framework style path lookup) and the module
is silently not built. This leads to frameworks not being modularized
by accident, which is pretty bad.
Add a warning and suggest the user to add the 'framework' qualifier
when we can prove that it's the case.
rdar://problem/39193062
llvm-svn: 333718
Unless the user uses -Wno-module-file-config-mismatch (or -Wno-error=...),
allow the AST reader to produce errors describing the nature of the config
mismatch.
llvm-svn: 333220
FunctionProtoType.
We previously re-evaluated the expression each time we wanted to know whether
the type is noexcept or not. We now evaluate the expression exactly once.
This is not quite "no functional change": it fixes a crasher bug during AST
deserialization where we would try to evaluate the noexcept specification in a
situation where we have not deserialized sufficient portions of the AST to
permit such evaluation.
llvm-svn: 331428
A @import targeting a top level module from a private module map file
(@import Foo_Private), would fail if there's any submodule declaration
around (module Foo.SomeSub) in the same private module map.
This happens because compileModuleImpl, when building Foo_Private, will
start with the private module map and will not parse the public one,
which leads to unsuccessful parsing of Foo.SomeSub, since top level Foo
was never parsed.
Declaring other submodules in the private module map is not common and
should usually be avoided, but it shouldn't fail to build. Canonicalize
compileModuleImpl to always look at the public module first, so that all
necessary information is available when parsing the private one.
rdar://problem/39822328
llvm-svn: 331322
Support for ObjC/C ODR-like semantics with structural equivalence
checking was added back in r306918. There enums are handled and also
checked for structural equivalence. However, at use time of
EnumConstantDecl, support was missing for preventing ambiguous
name lookup.
Add the missing bits for properly merging EnumConstantDecl.
rdar://problem/38374569
llvm-svn: 331232
During deserialization clang is currently missing the merging of
protocols into the canonical interface for the class extension.
This merging only currently happens during parsing and should also
be considered during deserialization.
rdar://problem/38724303
llvm-svn: 331063
Without these comments, by "luck" the contents of SomeKit's SKWidget.h
are precisely the same as SomeKitCore's SomeKitCore.h. This can create
havoc if anything canonicalizes on the inode and your filesystem assigns
a common inode to files with identical file content. Alternatively, if
your build system uses symlinks into a content-addressed-storage (as
Google's does), you end up with these files being symlinks to the same
file.
The end result is that Clang deduplicates them internally, and then
believes that the SomeKit framework includes the SomeKitCore.h header,
and does not include the SKWidget.h in SomeKit. This in turn results in
warnings in this test and eventually errors as Clang becomes confused
because the umbrella header for SomeKitCore has already been included
into another framework's module (SomeKit). Yay.
If anyone has a better idea about how to avoid this, I'm all ears.
Nothing other than causing the file content to change worked for me.
llvm-svn: 330184
framework module SomeKitCore {
...
export_as SomeKit
}
Given the module above, while generting autolink information during
codegen, clang should to emit '-framework SomeKitCore' only if SomeKit
was not imported in the relevant TU, otherwise it should use '-framework
SomeKit' instead.
rdar://problem/38269782
llvm-svn: 330152
Summary:
This patch extend getTargetDefines and implement handleTargetFeatures
and hasFeature. and define corresponding marco for those features.
Reviewers: asb, apazos, eli.friedman
Differential Revision: https://reviews.llvm.org/D44727
Patch by Kito Cheng.
llvm-svn: 329278
commit 519b97132a4c960e8dedbfe4290d86970d92e995
Author: Richard Trieu <rtrieu@google.com>
Date: Sat Mar 24 00:52:44 2018 +0000
[ODRHash] Support pointer and reference types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328404 91177308-0d34-0410-b5e6-96231b3b80d8
As it's breaking some tests. I've communicated with Richard offline about testcases.
llvm-svn: 329001
During reading C++ definition data for lambda we can access
CXXRecordDecl representing lambda before we finished reading the
definition data. This can happen by reading a captured variable which is
VarDecl, then reading its decl context which is CXXMethodDecl `operator()`,
then trying to merge redeclarable methods and accessing
enclosing CXXRecordDecl. The call stack looks roughly like
VisitCXXRecordDecl
ReadCXXRecordDefinition
VisitVarDecl
VisitCXXMethodDecl
mergeRedeclarable
getPrimaryContextForMerging
If we add fake definition data at this point, later we'll hit the assertion
Assertion failed: (!DD.IsLambda && !MergeDD.IsLambda && "faked up lambda definition?"), function MergeDefinitionData, file clang/lib/Serialization/ASTReaderDecl.cpp, line 1675.
The fix is to assign definition data before reading it. Fixes PR32556.
rdar://problem/37461072
Reviewers: rsmith, bruno
Reviewed By: rsmith
Subscribers: cfe-commits, jkorous-apple, aprantl
Differential Revision: https://reviews.llvm.org/D43494
llvm-svn: 328153
When skipping building the module for a private framework module,
LangOpts.CurrentModule isn't enough for implict modules builds; for
instance, in case a private module is built while building a public one,
LangOpts.CurrentModule doesn't reflect the -fmodule-name being passed
down, but instead the module name which triggered the build.
Store the actual -fmodule-name in LangOpts.ModuleName and actually
check a name was provided during compiler invocation in order to
skip building the private module.
rdar://problem/38434694
llvm-svn: 328053
This patch uses the infrastructure added in r326307 for enabling
non-trivial fields to be declared in C structs to allow __weak fields in
C structs in ARC.
This recommits r327206, which was reverted because it caused
module-enabled builders to fail. I discovered that the
CXXRecordDecl::CanPassInRegisters flag wasn't being set correctly in
some cases after I moved it to RecordDecl.
Thanks to Eric Liu for helping me investigate the bug.
rdar://problem/33599681
https://reviews.llvm.org/D44095
llvm-svn: 327870
All use declarations need to be directly placed in the top-level module
anyway, knowing the submodule doesn't really help. The header that has
the offending #include can easily be seen in the diagnostics source
location.
Review: https://reviews.llvm.org/D43673
llvm-svn: 326023
The tests that failed on a windows host have been fixed.
Original message:
Start setting dso_local for COFF.
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.
llvm-svn: 325940
Assume Foo.framework with two module maps and two modules Foo and
Foo_Private.
Framework authors need to skip building both Foo and Foo_Private when
using -fmodule-name=Foo, since both are part of the framework and used
interchangeably during compilation.
rdar://problem/37500098
llvm-svn: 325305
diagnostic settings using _Pragma within a macro.
The AST writer had previously been assuming that all diagnostic state
transitions would occur within a FileID corresponding to a file. When a
diagnostic state change occured within a macro, it was unable to form a
location for that state change and would instead corrupt the diagnostic state
of the "root" node (and thus that of the main compilation).
Also introduce a "#pragma clang __debug diag_mapping" debugging utility
that I added to track this issue down.
llvm-svn: 324695
This patch:
* fixes an incorrect sign-extension of unsigned values, when emitting
debug info metadata for enumerators
* the enumerators metadata is created with a flag, which determines
interpretation of the value bits (signed or unsigned)
* the enumerations metadata contains the underlying integer type and a
flag, indicating whether this is a C++ "fixed enum"
Differential Revision: https://reviews.llvm.org/D42736
llvm-svn: 324490
Using a BlockDecl in a default member initializer causes it to be attached to
CXXMethodDecl without its access specifier being set. This prevents a crash
where getAccess is called on this BlockDecl, since that method expects any
Decl in CXXRecord scope to have an access specifier.
llvm-svn: 322984
Summary:
Upstream LLVM is changing the the prototypes of the @llvm.memcpy/memmove/memset
intrinsics. This change updates the Clang tests for this change.
The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument
which is required to be a constant integer. It represents the alignment of the
dest (and source), and so must be the minimum of the actual alignment of the
two.
This change removes the alignment argument in favour of placing the alignment
attribute on the source and destination pointers of the memory intrinsic call.
For example, code which used to read:
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false)
will now read
call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false)
At this time the source and destination alignments must be the same (Step 1).
Step 2 of the change, to be landed shortly, will relax that contraint and allow
the source and destination to have different alignments.
llvm-svn: 322964
In certain combinations of templated classes and friend functions, the body
of friend functions does not get propagated along with function signature.
Exclude friend functions for hashing to avoid this case.
llvm-svn: 322350
Any hashing for methods should be able to compile this test case without
emitting an error. Since the class and method come from the same header from
each module, there should be no messages about ODR violations.
llvm-svn: 321924
Attempting to recompute it are doomed to fail because the IDNS of a declaration
is not necessarily preserved across serialization and deserialization (in turn
because whether a friend declaration is visible depends on whether some prior
non-friend declaration exists).
llvm-svn: 321921
redecl chain for an imported declaration, make sure to check the IDNS of prior
imported decls.
Otherwise we can end up finding an invisible friend declaration and incorrectly
believing that it should be visible.
llvm-svn: 321916
When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.
This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.
Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html
Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html
Differential Revision: https://reviews.llvm.org/D31269
rdar://problem/23612102
llvm-svn: 321855
When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.
This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.
Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html
Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html
Differential Revision: https://reviews.llvm.org/D31269
rdar://problem/23612102
llvm-svn: 321781
Summary:
cp -a is neither part of POSIX nor the LSB. The nearest equivalent under
POSIX is cp -RPp; however, cp -R is sufficient for the intended purpose.
test/Modules/crash-vfs-headermaps.m is not updated since it requires
system-darwin anyway.
Reviewers: bruno
Reviewed By: bruno
Subscribers: bruno, rcraik, cfe-commits
Differential Revision: https://reviews.llvm.org/D41545
llvm-svn: 321778
When a type is only used as a template parameter and that type is the
only type imported from another #include'd module, no skeleton CU for
that module is generated, so a consumer doesn't know where to find the
type definition. By emitting an import declaration, we can force a
skeleton CU to be generated for each imported module.
rdar://problem/36266156
llvm-svn: 321754
Extend the hashing to functions, which allows detection of function definition
mismatches across modules. This is a re-commit of r320230.
llvm-svn: 321395
In case `@import Foo.Private` fails because the submodule doesn't exist,
look for `Foo_Private` (if available) and build/load that module
instead. In that process emit a warning and tell the user about the
assumption.
The intention here is to assist all existing private modules owners
(in ObjC and Swift) to migrate to the new `Foo_Private` syntax.
rdar://problem/36023940
llvm-svn: 321342
We used to advertise private modules to be declared as submodules
(Foo.Private). This has proven to not scale well since private headers
might carry several dependencies, introducing unwanted content into the
main module and often causing dep cycles.
Change the canonical way to name it to Foo_Private, forcing private
modules as top level ones, and provide warnings under -Wprivate-module
to suggest fixes for other private naming. Update documentation to
reflect that.
rdar://problem/31173501
llvm-svn: 321337
An unscoped enumeration used as template argument, should not have any
qualified information about its enclosing scope, as its visibility is
global.
In the case of scoped enumerations, they must include information
about their enclosing scope.
Patch by Carlos Alberto Enciso!
Differential Revision: https://reviews.llvm.org/D39239
llvm-svn: 321312
When mixing PCH and Implicit Modules, missing a header search path
can lead to the implicit built PCM to complaint about not finding its
matching module map.
Instead of adding more magic to implicit modules engine, add a note to
help the user add the appropriate path.
rdar://problem/33388847
llvm-svn: 318503
Add a mix of postive and negative tests to check that wrong Decls won't be
flagged in the diagnostic. Split the check everything test and moved the
pieces closer to where the related tests are.
llvm-svn: 317394
Since they'll likely (not always - if the address is taken, etc) be
inlined away, even at -O0, separately provided weak definitions are
likely to be unused so skip all of that.
llvm-svn: 317279
Consistent with various workarounds in the backwards compatible modules
that allow static functions in headers to exist, be deduplicated to some
degree, and not generally fail right out of the gate... do the same with
modular codegen as there are enough cases (including in libstdc++ and in
LLVM itself - though I cleaned up the easy ones) that it's worth
supporting as a migration/backcompat step.
Simply create a separate, internal linkage function in each object that
needs it. If an available_externally/modularized function references a
static function, but the modularized function is eventually dropped and
not inlined, the static function will be dropped as unreferenced.
llvm-svn: 317274
for instantiating its definition.
We model the 'inline'ness as being instantiated with the static data member in
order to track whether the declaration has become a definition yet.
llvm-svn: 317147
They might have different visibility, and thus discarding all but one of them
can result in rejecting valid code. Also fix name lookup to cope with multiple
using-directives being found that denote the same namespace, where some are not
visible -- don't cache an "already visited" state for a using-directive that we
didn't visit because it was hidden.
llvm-svn: 316965
This is breaking a build of https://github.com/abseil/abseil-cpp and so
likely not really NFC. Also reverted subsequent r314956/7.
I'll forward reproduction instructions to Richard.
llvm-svn: 315439
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.
llvm-svn: 315379
This works around a language issue where adding a typedef name for linkage
purposes changes the linkage of an already-defined class after it becomes
complete.
llvm-svn: 315256
Summary: Also makes them pass on Darwin, if the default target triple is a Linux triple.
Reviewers: bruno, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38364
llvm-svn: 314524
Introduce a new "export_as" directive for top-level modules, which
indicates that the current module is a "private" module whose symbols
will eventually be exported through the named "public" module. This is
in support of a common pattern in the Darwin ecosystem where a single
public framework is constructed of several private frameworks, with
(currently) header duplication and some support from the linker.
Addresses rdar://problem/34438420.
llvm-svn: 313316
Summary:
This adds a test that checks if the using declaration in classes still works as intended with modules.
The motivation for this is that we tried to add a shortcut to `removeDecl` that would skip the removal of declarations from the lookup table if they are hidden. This optimization passed the clang test suite but actually broke the using declaration in combination with -fmodules-local-submodule-visibility. In this mode we hide all decls from other modules such as by chance the parent method, in which case don't remove the parent method from the lookup table and get ambiguous lookup errors. After this patch we now correctly see if this behavior is broken by a patch like this in the test suite.
Reviewers: v.g.vassilev
Reviewed By: v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37180
llvm-svn: 311991
The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t.
This patch removes %T in clang.
Differential Revision: https://reviews.llvm.org/D36437
llvm-svn: 310950
declarations that are made visible after the dummy is parsed and ODR verified
Prior to this commit the
"(getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one."),"
assertion failure was triggered during semantic analysis of the dummy
tag declaration that was declared in another tag declaration because its
lexical context did not point to the outer tag decl.
rdar://32292196
llvm-svn: 310706
When non-modular headers are imported while not building a module but
in -fmodules mode, be conservative and preserve the default #import
semantic: do not reenter headers.
rdar://problem/33745031
llvm-svn: 310605
CurrentDir was set as the path of the current module, but that can change as
part of a chain of loaded modules.
When we try to locate a file mentioned in a module that does not exist, we use
a heuristic to look at the relative path between the original location of the
module and the file we look for, and use that relatively to the CurrentDir.
This only works if CurrentDir is the same as the (current) path of the module
file the file was mentioned in; if it is not, we look at the path relatively to
the wrong directory, and can end up reading random unrelated files that happen
to have the same name.
This patch fixes this by using the BaseDirectory of the module file the file
we look for was mentioned in instead of the CurrentDir heuristic.
Differential Revision: https://reviews.llvm.org/D35828
llvm-svn: 308962
This patch adds an early exit to CGDebugInfo::completeClassData() when
compiling with -gmodules and the to-be-completed type is available in
a clang module.
rdar://problem/23599990
llvm-svn: 308938
Previously it was uninitialized and thus always defaulted to "<stdin>".
This is mostly a cosmetic change that helps making the debug info more readable.
llvm-svn: 308397
FunctionDecl already hashes most of the information in the function's type.
Add hashing of the return type, and skip hashing the function's type to avoid
redundancy and extra work when computing the hash.
llvm-svn: 307986
Allow ODR for ObjC/C in the sense that we won't keep more that
one definition around (merge them). However, ensure the decl
pass the structural compatibility check in C11 6.2.7/1, for that,
reuse the structural equivalence checks used by the ASTImporter.
Few other considerations:
- Create error diagnostics for tag types mismatches and thread
them into the structural equivalence checks.
- Note that by doing this we only support redefinition between types
that are considered "compatible types" by C.
This is mixed approach of the suggestions discussed in
http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html
Differential Revision: https://reviews.llvm.org/D31778
rdar://problem/31909368
llvm-svn: 306918
Summary:
Add a test for the change to ASTReader that reproduces the
logic for consolidating multiple ObjC interface definitions to the
case of multiple ObjC protocol definitions.
This test is a modified copy of the test that accompanied the original
change to interfaces, in 2ba1979.
Reviewers: bruno
Reviewed By: bruno
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34788
llvm-svn: 306732
modules to preprocessing of nested .pcm files.
Making those module files available results in loading more .pcm files than
necessary, and potentially in misbehavior if a module makes itself visible
during its own compilation (as parts of that module that have not yet been
processed would then become visible).
llvm-svn: 306320
These VarDecl's are static data members of classes. Since the initializers are
also hashed, this also provides checking for default arguments to methods.
llvm-svn: 305543
If specified, when preprocessing, the contents of imported .pcm files will be
included in preprocessed output. The resulting preprocessed file can then be
compiled standalone without the module sources or .pcm files.
llvm-svn: 305116
as part of a compilation.
This is intended for two purposes:
1) Writing self-contained test cases for modules: we can now write a single
source file test that builds some number of module files on the side and
imports them.
2) Debugging / test case reduction. A single-source testcase is much more
amenable to reduction, compared to a VFS tarball or .pcm files.
llvm-svn: 305101
replaced by visible decls.
Make sure that all paths through checkCorrectionVisibility set the
RequiresImport flag appropriately, so we don't end up using a stale value.
Patch by Jorge Gorbe!
Differential Revision: https://reviews.llvm.org/D30963
llvm-svn: 304745
replay the steps taken to create the AST file with the preprocessor-only action
installed to produce preprocessed output.
This can be used to produce the preprocessed text for an existing .pch or .pcm
file.
llvm-svn: 304726
This patch adds support for a `header` declaration in a module map to specify
certain `stat` information (currently, size and mtime) about that header file.
This has two purposes:
- It removes the need to eagerly `stat` every file referenced by a module map.
Instead, we track a list of unresolved header files with each size / mtime
(actually, for simplicity, we track submodules with such headers), and when
attempting to look up a header file based on a `FileEntry`, we check if there
are any unresolved header directives with that `FileEntry`'s size / mtime and
perform deferred `stat`s if so.
- It permits a preprocessed module to be compiled without the original files
being present on disk. The only reason we used to need those files was to get
the `stat` information in order to do header -> module lookups when using the
module. If we're provided with the `stat` information in the preprocessed
module, we can avoid requiring the files to exist.
Unlike most `header` directives, if a `header` directive with `stat`
information has no corresponding on-disk file the enclosing module is *not*
marked unavailable (so that behavior is consistent regardless of whether we've
resolved a header directive, and so that preprocessed modules don't get marked
unavailable). We could actually do this for all `header` directives: the only
reason we mark the module unavailable if headers are missing is to give a
diagnostic slightly earlier (rather than waiting until we actually try to build
the module / load and validate its .pcm file).
Differential Revision: https://reviews.llvm.org/D33703
llvm-svn: 304515
This patch makes it an error to have a mismatch between the enabled
sanitizers in a CU, and in any module being imported into the CU. Only
mismatches between non-modular sanitizers are treated as errors.
This patch also includes non-modular sanitizers in module hashes, in
order to ensure module rebuilds occur when -fsanitize=X is toggled on
and off for non-modular sanitizers, and to cut down on module rebuilds
when the option is toggled for modular sanitizers.
This fixes a longstanding issue with implicit modules and sanitizers,
which Duncan originally diagnosed.
When building with implicit modules it's possible to hit a scenario
where modules are built without -fsanitize=address, and are subsequently
imported into CUs with -fsanitize=address enabled. This causes strange
failures at runtime. The case Duncan found affects libcxx, since its
vector implementation behaves differently when ASan is enabled.
Implicit module builds should "just work" when -fsanitize=X is toggled
on and off across multiple compiler invocations, which is what this
patch does.
Differential Revision: https://reviews.llvm.org/D32724
llvm-svn: 304463
to the original module map.
Also use the path and name of the original module map when emitting that
information into the .pcm file. The upshot of this is that the produced .pcm
file will track information for headers in their original locations (where the
module was preprocessed), not relative to whatever directory the preprocessed
module map was in when it was built.
llvm-svn: 304346
and it has an include guard, produce callbacks for a module import, not for a
skipped non-modular header.
Fixes -E output when preprocessing a module to list these cases as a module
import, rather than suppressing the #include and losing the import side effect.
llvm-svn: 304183
Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33538
llvm-svn: 304107
Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33538
llvm-svn: 304054
We currenltly assert when want to diagnose a missing import and the decl
in question is already visible. It turns out that the decl in question
might be visible because another decl from the same module actually made
the module visible in a previous error diagnostic.
Remove the assertion and avoid re-exporting the module if it's already
visible.
rdar://problem/27975402
Differential Revision: https://reviews.llvm.org/D32828
llvm-svn: 303705
When reaching the end of a module, we used to convert its macros to
ModuleMacros but also leave them in the MacroDirective chain for the
identifier. This meant that every lookup of such a macro would find two
(identical) definitions. It also made it difficult to determine the correct
owner for a macro when reaching the end of a module: the most recent
MacroDirective in the chain could be from an #included submodule rather than
the current module.
Simplify this: whenever we convert a MacroDirective to a ModuleMacro when
leaving a module, clear out the MacroDirective chain for that identifier, and
just rely on the ModuleMacro to provide the macro definition information.
(We don't want to do this for local submodule visibility mode, because in that
mode we maintain a distinct MacroDirective chain for each submodule, and we
need to keep around the prior MacroDirective in case we re-enter the submodule
-- for instance, if its header is #included more than once in a module build,
we need the include guard directive to stick around. But the problem doesn't
arise in this case for the same reason: each submodule has its own
MacroDirective chain, so the macros don't leak out of submodules in the first
place.)
This reinstates r302932, reverted in r302947, with a fix for a bug that
resulted in us sometimes losing macro definitions due to failing to clear out
the overridden module macro list when promoting a directive to a module macro.
llvm-svn: 303468
specification and the TU to the new module.
This is necessary to get the module ownership correct for entities that we
temporarily hang off the TranslationUnitDecl, such as template parameters and
function parameters.
llvm-svn: 303373
inferring based on the current module at the point of creation.
This should result in no functional change except when building a preprocessed
module (or more generally when using #pragma clang module begin/end to switch
module in the middle of a file), in which case it allows us to correctly track
the owning module for declarations. We can't map from FileID to module in the
preprocessed module case, since all modules would have the same FileID.
There are still a couple of remaining places that try to infer a module from a
source location; I'll clean those up in follow-up changes.
llvm-svn: 303322
retrieving the identifer info for an Objective-C keyword
This commit fixes an assertion that's triggered in getIdentifier when the token
is an annotation token.
rdar://32225463
llvm-svn: 303246
rather than waiting until it's queried.
Currently this is only applied to local submodule visibility mode, as we don't
yet allocate storage for the owning module in non-local-visibility modules
compilations.
This reinstates r302965, reverted in r303037, with a fix for the reported
crash, which occurred when reparenting a local declaration to be a child of
a hidden imported declaration (specifically during template instantiation).
llvm-svn: 303224
The AST merges NamespaceDecls, but for module debug info it is
important to put a namespace decl (or rather its children) into the
correct (sub-)module, so we need to use the parent module of the decl
that triggered this namespace to be serialized as a second key when
looking up DINamespace nodes.
rdar://problem/29339538
llvm-svn: 302840
Diagnostics related to redefinition errors that point to the same header
file do not provide much information that helps users fixing the issue.
- In the modules context, it usually happens because of non modular
includes.
- When modules aren't involved it might happen because of the lack of
header guards.
Enhance diagnostics in these scenarios.
Differential Revision: https://reviews.llvm.org/D28832
rdar://problem/31669175
llvm-svn: 302765
When a type in a class is from a typedef, only check the canonical type. Skip
checking the intermediate underlying types. This is in response to PR 32965
llvm-svn: 302505
In r298391 we fixed the umbrella framework model to work when submodules
named "Private" are used. This complements the work by allowing the
umbrella framework model to work in general.
rdar://problem/31790067
llvm-svn: 302491
To support this, an optional marker "#pragma clang module contents" is
recognized in module map files, and the rest of the module map file from that
point onwards is treated as the source of the module. Preprocessing a module
map produces the input module followed by the marker and then the preprocessed
contents of the module.
Ignoring line markers, a preprocessed module might look like this:
module A {
header "a.h"
}
#pragma clang module contents
#pragma clang module begin A
// ... a.h ...
#pragma clang module end
The preprocessed output generates line markers, which are not accepted by the
module map parser, so -x c++-module-map-cpp-output should be used to compile
such outputs.
A couple of major parts do not work yet:
1) The files that are listed in the module map must exist on disk, in order to
build the on-disk header -> module lookup table in the PCM file. To fix
this, we need the preprocessed output to track the file size and other stat
information we might use to build the lookup table.
2) Declaration ownership semantics don't work properly yet, since mapping from
a source location to a module relies on mapping from FileIDs to modules,
which we can't do if module transitions can occur in the middle of a file.
llvm-svn: 302309
These pragmas are intended to simulate the effect of entering or leaving a file
with an associated module. This is not completely implemented yet: declarations
between the pragmas will not be attributed to the correct module, but macro
visibility is already functional.
Modules named by #pragma clang module begin must already be known to clang (in
some module map that's either loaded or on the search path).
llvm-svn: 302098
The intent for an explicit module build is that the diagnostics produced within
the module are those that were configured when the module was built, not those
that are enabled within a user of the module. This includes diagnostics that
don't actually show up until the module is used (for instance, diagnostics
produced during template instantiation and weird cases like -Wpadded).
We serialized and restored the diagnostic state for individual warning groups,
but previously did not track the state for flags like -Werror and -Weverything,
which are implemented as separate bits rather than as part of the diagnostics
mapping information.
llvm-svn: 301992
If a file has no diagnostic pragmas, we build its diagnostic state lazily, but
in this case we never set up the root state to be the diagnostic state in which
the module was originally built, so the diagnostic flags for files in the
module with no diagnostic pragmas were incorrectly based on the user of the
module rather than the diagnostic state when the module was built.
llvm-svn: 301846
These tests do not appear to be Darwin-specific, and this REQUIRES: appears to
be hiding a real bug; this change is just restoring the prior state to get the
buildbots happy again while we investigate. (The system-darwin requirement is
covered by PR32851.)
llvm-svn: 301840
Also remove the apparently-unneeded REQUIRES (the tests also pass on at least
Linux, and don't appear to have anything Darwin-specific in them).
llvm-svn: 301731
Many of our supported configurations support modules but do not have any
first-class syntax to perform a module import. This leaves us with a problem:
there is no way to represent the expansion of a #include that imports a module
in the -E output for such languages. (We don't want to just leave it as a
#include because that requires the consumer of the preprocessed source to have
the same file system layout and include paths as the creator.)
This patch adds a new pragma:
#pragma clang module import MODULE.NAME.HERE
that imports a module, and changes -E and -frewrite-includes to use it when
rewriting a #include that maps to a module import. We don't make any attempt
to use a native language syntax import if one exists, to get more consistent
output. (If in the future, @import and #include have different semantics in
some way, the pragma will track the #include semantics.)
llvm-svn: 301725
action to the general FrontendAction infrastructure.
This permits applying -E, -ast-dump, -fsyntax-only, and so on to a module map
compilation. (The -E form is not currently especially useful yet as there's no
good way to take the output and use it to actually build a module.)
In order to support this, -cc1 now accepts -x <lang>-module-map in all cases
where it accepts -x <lang> for a language we can parse (not ir/ast). And for
uniformity, we also accept -x <lang>-header for all such languages (we used
to reject for cuda and renderscript), and -x <lang>-cpp-output for all such
languages (we used to reject for c, cl, and renderscript).
(None of these new alternatives are accepted by the driver yet, so no
user-visible changes.)
llvm-svn: 301610
One of the -Wincomplete-umbrella warnings diagnoses when a header is present in
the directory but it's not present in the umbrella header. Currently, this
warning only happens on top level modules; any submodule using an umbrella
header does not get this warning. Fix that by also considering the submodules.
Differential Revision: https://reviews.llvm.org/D32576
rdar://problem/22623686
llvm-svn: 301597
Do not add an overload if the function doesn't have a prototype; this
can happen if, for instance, a misplaced/malformed call site is
considered like a declaration for recovery purposes.
rdar://problem/31306325
llvm-svn: 301453
Use definition from canonical decl when checking for designated
initializers. This is necessary since deserialization of a interface
might reuse the definition from the canonical one (see r281119).
rdar://problem/29360655
llvm-svn: 301382
When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.
This reinstates r300650, reverted in r300659, with a fix for a regression
reported by Chandler after commit.
llvm-svn: 300938
Use a macro to generate the struct with all decls. Previously, four identical
changes would be needed to update this test. This macro reduces that to one
location. Added two other tests for issues that triggered false positives
during testing.
llvm-svn: 300814
modules but exposes much more widespread issues. Example and more
information is on the review thread for r300650.
Original commit summary:
[modules] Properly look up the owning module for an instantiation of a merged template.
llvm-svn: 300659
When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.
llvm-svn: 300650
Vassil Vassilev