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
