The goal of this is to fix a bug in modules where we'd merge
FunctionDecls that differed in their pass_object_size attributes. Since
we can overload on the presence of pass_object_size attributes, this
behavior is incorrect.
We don't represent `N` in `pass_object_size(N)` as part of
ExtParameterInfo, since it's an error to overload solely on the value of
N. This means that we have a bug if we have two modules that declare
functions that differ only in their pass_object_size attrs, like so:
// In module A, from a.h
void foo(char *__attribute__((pass_object_size(0))));
// In module B, from b.h
void foo(char *__attribute__((pass_object_size(1))));
// In module C, in main.c
#include "a.h"
#include "b.h"
At the moment, we'll merge the foo decls, when we should instead emit a
diagnostic about an invalid overload. We seem to have similar (silent)
behavior if we overload only on the return type of `foo` instead; I'll
try to find a good place to put a FIXME (or I'll just file a bug) soon.
This patch also fixes a bug where we'd not output the proper extended
parameter info for declarations with pass_object_size attrs.
llvm-svn: 296076
Two functions that differ only in their enable_if attributes are
considered overloads, so we should check for those when we're trying to
figure out if two functions are mergeable.
We need to do the same thing for pass_object_size, as well. Looks like
that'll be a bit less trivial, since we sometimes do these merging
checks before we have pass_object_size attributes available (see the
merge checks in ASTDeclReader::VisitFunctionDecl that happen before we
read parameters, and merge checks in calls to ReadDeclAs<>()).
llvm-svn: 295252
Following up on r291465 after a regression in r276159. When we use
-fmodule-name=X while building a PCH, modular headers in X will be
textually included and the compiler knows that we are not building
module X, so don't serialize such headers in the PCH as being part of a
module, because at this point they are not.
This was causing subtle bugs and malformed AST crashes, for instance,
when using the PCH in subsequent compiler invocation with -fmodules, the
HFI for a modular header would map to the PCH, which would force a
module load of and unexistent module ID.
rdar://problem/30171164
llvm-svn: 294361
First pass at generating weak definitions of inline functions from module files
(& skipping (-O0) or emitting available_externally (optimizations)
definitions where those modules are used).
External functions defined in modules are emitted into the modular
object file as well (this may turn an existing ODR violation (if that
module were imported into multiple translations) into valid/linkable
code).
Internal symbols (static functions, for example) are not correctly
supported yet. The symbol will be produced, internal, in the modular
object - unreferenceable from the users.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D28845
llvm-svn: 293456
another declaration, ensure we actually serialize / deserialize that
declaration.
Before this patch, if another copy of the typedef were merged with the parsed
version, we would emit type information referring to the merged version and
consequently emit nothing about the parsed anonymous struct. This resulted in
us losing information, particularly the visible merged module set for the
parsed definition. Force that information to be emitted and to be loaded when
the typedef is used.
llvm-svn: 293219
Rather than storing a single flat list of SourceLocations where the diagnostic
state changes (in source order), we now store a separate list for each FileID
in which there is a diagnostic state transition. (State for other files is
built and cached lazily, on demand.) This has two consequences:
1) We can now sensibly support modules, and properly track the diagnostic state
for modular headers (this matters when, for instance, triggering instantiation
of a template defined within a module triggers diagnostics).
2) It's much faster than the old approach, since we can now just do a binary
search on the offsets within the FileID rather than needing to call
isBeforeInTranslationUnit to determine source order (which is surprisingly
slow). For some pathological (but real world) files, this reduces total
compilation time by more than 10%.
For now, the diagnostic state points for modules are loaded eagerly. It seems
feasible to defer this until diagnostic state information for one of the
module's files is needed, but that's not part of this patch.
llvm-svn: 293123
When a textual header is present inside a umbrella dir but not in the
header, we get the misleading warning:
warning: umbrella header for module 'FooFramework' does not include
header 'Baz_Private.h'
The module map in question:
framework module FooFramework {
umbrella header "FooUmbrella.h"
export *
module * { export * }
module Private {
textual header "Baz_Private.h"
}
}
Fix this by taking textual headers into account.
llvm-svn: 291794
Fixes a crash in modules where the template class decl becomes the most recent
decl in the redeclaration chain and forcing the template instantiator try to
instantiate the friend declaration, rather than the template definition.
In practice, A::list<int> produces a TemplateSpecializationType
A::__1::list<int, allocator<type-parameter-0-0> >' failing to replace to
subsitute the default argument to allocator<int>.
Kudos Richard Smith (D28399).
llvm-svn: 291753
a header of that same module.
This fixes a regression caused by r280409.
rdar://problem/29930553
This is an updated version for r291628 (which was reverted in r291688).
llvm-svn: 291689
filter out the implicilty imported modules at CodeGen instead of removing the
implicit ImportDecl when an implementation TU of a module imports a header of
that same module.
llvm-svn: 291688
Textual headers and builtins that are #import'd from different
modules should get re-entered when these modules are independent
from each other.
Differential Revision: https://reviews.llvm.org/D26267
rdar://problem/25881934
llvm-svn: 291644
In r276159, we started to say that a module X is defined in a pch if we specify
-fmodule-name when building the pch. This caused a regression that reports
module X is defined in both pch and pcm if we generate the pch with
-fmodule-name=X and then in a separate clang invocation, we include the pch and
also import X.pcm.
This patch adds an option CompilingPCH similar to CompilingModule. When we use
-fmodule-name=X while building a pch, modular headers in X will be textually
included and the compiler knows that we are not building module X, so we don't
put module X in SUBMODULE_DEFINITION of the pch.
Differential Revision: http://reviews.llvm.org/D28415
llvm-svn: 291465
Summary:
The module system supports accompanying a primary module (say Foo) with
an auxiliary "private" module (defined in an adjacent module.private.modulemap
file) that augments the primary module when associated private headers are
available. The feature is intended to be used to augment the primary
module with a submodule (say Foo.Private), however some users in the wild
are choosing to augment the primary module with an additional top-level module
with a "similar" name (in all cases so far: FooPrivate).
This "works" when a user of the module initially imports a private header,
such as '#import "Foo/something_private.h"' since the Foo import winds up
importing FooPrivate in passing. But if the import is subsequently recorded
in a PCH file, reloading the PCH will fail to validate because of a cross-check
that attempts to find the module.modulemap (or module.private.modulemap) using
HeaderSearch algorithm, applied to the "FooPrivate" name. Since it's stored in
Foo.framework/Modules, not FooPrivate.framework/Modules, the check fails and
the PCH is rejected.
This patch adds a compensatory workaround in the HeaderSearch algorithm
when searching (and failing to find) a module of the form FooPrivate: the
name used to derive filesystem paths is decoupled from the module name
being searched for, and if the initial search fails and the module is
named "FooPrivate", the filesystem search name is altered to remove the
"Private" suffix, and the algorithm is run a second time (still looking for
a module named FooPrivate, but looking in directories derived from Foo).
Accompanying this change is a new warning that triggers when a user loads
a module.private.modulemap that defines a top-level module with a different
name from the top-level module defined in its adjacent module.modulemap.
Reviewers: doug.gregor, manmanren, bruno
Subscribers: bruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D27852
llvm-svn: 290219
import can't appear here" diagnostic if an already-visible module is textually
entered (because we have the module map but not the AST file) within a
function/namespace scope.
llvm-svn: 288737
Summary: When merging definitions with ModulesLocalVisibility enabled it's important to make deleted definitions implicitly inline, otherwise they'll be diagnosed as a redefinition.
Reviewers: silvas, manmanren, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26143
llvm-svn: 285655
This used to work before r284797 + r285152, which exposed something
interesting; some users include builtins from umbrella headers.
Clang should emit a warning to warn users this is not a good practice
and umbrella headers shouldn't get the
implicitly-add-the-builtin-version behavior for builtin header names.
While we're not there, add the testcase to represent the way it
currently works.
llvm-svn: 285377
If two modules contain duplicate class definitions the lookup result can contain
more than 2 elements. Sift the lookup results until we find a field decl.
It is not necessary to do ODR checks in place as they done elsewhere.
This should fix issues when compiling with libstdc++ 5.2 and 6.2.
Patch developed in collaboration with Richard Smith!
llvm-svn: 285184
headers. We previously got this check backwards and treated the wrapper header
as being textual.
This is important because our wrapper headers sometimes inject macros into the
system headers that they #include_next, and sometimes replace them entirely.
llvm-svn: 285152
The 'no_undeclared_includes' attribute should be used in a module to
tell that only non-modular headers and headers from used modules are
accepted.
The main motivation behind this is to prevent dep cycles between system
libraries (such as darwin) and libc++.
Patch by Richard Smith!
llvm-svn: 284797
This is a followup to regression introduced in r284284.
This should fix our libstdc++ modules builds.
https://reviews.llvm.org/D25678
Reviewed by Richard Smith!
llvm-svn: 284577
This reverts commit r284176. It still marks some modules as invisible
that should be visible. Will follow up with the author with a test case.
llvm-svn: 284382
1) Merge and demote variable definitions when we find a redefinition in
MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach
the second case if it's the addition of the initializer itself that converts an
existing declaration into a definition).
2) When rebuilding a redeclaration chain for a variable, if we merge two
definitions together, mark the definitions as merged so the retained definition
is made visible whenever the demoted definition would have been.
Original commit message (from r283882):
[modules] PR28752: Do not instantiate variable declarations which are not visible.
Original patch by Vassil Vassilev! Changes listed above are mine.
llvm-svn: 284284
compiles without -fmodules-local-submodule-visibility. Original commit message:
[modules] When merging one definition into another, propagate the list of
re-exporting modules from the discarded definition to the retained definition.
llvm-svn: 284176
In r276159, we started to defer emitting initializers for VarDecls, but
forgot to add the initializers for non-C++ language.
rdar://28740482
llvm-svn: 284142
Original message:
"[modules] PR28752: Do not instantiate variable declarations which are not visible.
https://reviews.llvm.org/D24508
Patch developed in collaboration with Richard Smith!"
llvm-svn: 284008
the resulting specialization is not referenced by the rest of the AST. This
both avoids performing unnecessary reinstantiations in downstream users of the
AST file and fixes a bug (breaking modules self-host right now) where we would
sometimes fail to emit a definition of a class template specialization if we
imported just a declaration of it from elsewhere (see new testcase for reduced
example).
llvm-svn: 283489
The deserialization of redeclartion can cause seg fault since getCanonicalDecl
of the redeclaration returns the lookup result on the ObjCContainerDecl,
which can be null if FindExternalVisibleDeclsByName is not done updating
the lookup results.
The fix is to return the redeclaration itself as the canonical decl. Note that
the handling for redeclaration of ObjCMethodDecl is not in line with other
redeclarables.
rdar://28488466
llvm-svn: 283145
In c++1z, static_assert is not required to have a StringLiteral message, where
previously it was required. Update the AST Reader to be able to handle a
null StringLiteral.
llvm-svn: 281286
When deserializing ObjCInterfaceDecl with definition data, if we already have
a definition, try to keep the definition invariant; also pull in the
categories even if it is not what getDefinition returns (this effectively
combines categories).
rdar://27926200
rdar://26708823
llvm-svn: 281119
