| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19048
llvm-svn: 268344
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a selector, the entry should be complete, containing everything introduced by
that module and all modules it imports.
Before writing out the method pool of a module, we sync up the out of date
selectors by pulling in methods for the selectors, from all modules it imports.
In ReadMethodPool, after pulling in the method pool entry for module A, this
lets us skip the modules that module A imports.
rdar://problem/25900131
llvm-svn: 268091
|
|
|
|
| |
llvm-svn: 267882
|
|
|
|
|
|
|
| |
the current language doesn't have an import syntax and we can figure out a
suitable file to include.
llvm-svn: 267802
|
|
|
|
| |
llvm-svn: 267744
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Decl::isUsed has a value for every decl. In non-module builds it is very
difficult (but possible) to break this invariant but when we walk up the redecl
chain we find the neccessary information.
When deserializing the decls from a module it is much more difficult to update
correctly this invariant. The patch centralizes the information whether a decl
is used in the canonical decl marking the entire entity as being used.
Fixes https://llvm.org/bugs/show_bug.cgi?id=27401
Patch by Cristina Cristescu and me.
Thanks to Richard Smith who helped to debug and understand the issue!
Reviewed by Richard Smith.
llvm-svn: 267691
|
|
|
|
|
|
|
|
|
|
|
| |
table for a module / PCH, never map from a normal declaration of a class to an
injected-class-name declaration (or vice versa). Those declarations live in
distinct lookup tables and should not be confused.
We really shouldn't be using a CXXRecordDecl to represent an
injected-class-name in the first place; I've filed PR27532 so we don't forget.
llvm-svn: 267632
|
|
|
|
|
|
| |
Thanks again to Richard Smith for pointing this out.
llvm-svn: 267630
|
|
|
|
|
|
| |
specializations.
llvm-svn: 267612
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instantiation is in a module.
This patch fixes the condition for determining whether the debug info for a
template instantiation will exist in an imported clang module by:
- checking whether the ClassTemplateSpecializationDecl is complete and
- checking that the instantiation was in a module by looking at the first field.
I also added a negative check to make sure that a typedef to a forward-declared
template (with the definition outside of the module) is handled correctly.
http://reviews.llvm.org/D19443
rdar://problem/25553724
llvm-svn: 267464
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the compile unit that contains their implementation even if their
interface is declared in a module.
The private @implementation of an @interface may have additional
hidden ivars so we should not defer to the public version of the
type that is found in the module.
<rdar://problem/25541798>
llvm-svn: 266937
|
|
|
|
| |
llvm-svn: 266353
|
|
|
|
|
|
|
|
|
|
|
| |
processed update records. If an update record adds a definition, we need to
merge that with any pre-existing definition to determine which the canonical
definition is before we apply the visible update, otherwise we wouldn't know
where to apply it.
Thanks to Vassil Vassilev for help reducing this and tracking down the problem.
llvm-svn: 265848
|
|
|
|
| |
llvm-svn: 265838
|
|
|
|
| |
llvm-svn: 265599
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VFS YAML files contain empty directory entries to describe that it's
returning from a subdirectory before describing new files in the parent.
In the future, we should properly sort and write YAML files avoiding
such empty dirs and mitigate the extra recurson cost. However, since
this is used by previous existing YAMLs, make the traversal work in
their presence.
rdar://problem/24499339
llvm-svn: 264970
|
|
|
|
|
|
|
|
|
|
| |
underlying type.
Fixes https://llvm.org/bugs/show_bug.cgi?id=26014
Reviewed by Richard Smith.
llvm-svn: 264937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases a slot for an identifier is requested but it gets written to
another module, causing an assertion.
At the point when we start serializing Rtypes, we have no imported IdentifierID
for float_round_style. We start serializing stuff and allocate an ID for it.
Then, during the serialization process, we pull in the identifier info for it
from TSchemaHelper. Finally, WriteIdentifierTable decides that the identifier
has not changed since it was deserialized, so doesn't emit it.
Fixes https://llvm.org/bugs/show_bug.cgi?id=27041
Discussed on IRC with Richard Smith. Agreed on post commit review if needed.
llvm-svn: 264913
|
|
|
|
| |
llvm-svn: 264908
|
|
|
|
|
|
|
|
|
|
| |
The System/ mock is large and too complex for this test. It can cause
the tests to fail in mysterious ways as it depends on the resource dir
being present, which is not really supported for driver tests (using
%clang instead of %clang_cc1). Copy the tree and trim out all the
%unnecessary fat.
llvm-svn: 263718
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
another module.
When clang adds argument dependent lookup candidates, it can perform template
instantiation. For example, it can instantiate a templated friend function and
register it in the enclosing namespace's lookup table.
Fixes https://llvm.org/bugs/show_bug.cgi?id=24954
Reviewed by Richard Smith.
llvm-svn: 263634
|
|
|
|
|
|
| |
implementation units of modules rather than interface units.
llvm-svn: 263449
|
|
|
|
|
|
|
|
| |
whose DeclContext is not yet complete by deferring their emission.
rdar://problem/24918680
llvm-svn: 262851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we import a module that has a complete array type and one that has an
incomplete array type, the declaration found by name lookup might be the one with
the incomplete type, possibly resulting in rejects-valid.
Now, the name lookup prefers decls with a complete array types. Also,
diagnose cases when the redecl chain has array bound, different from the merge
candidate.
Reviewed by Richard Smith.
llvm-svn: 262189
|
|
|
|
|
|
|
|
|
|
|
|
| |
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
llvm-svn: 261372
|
|
|
|
|
|
|
|
|
|
| |
When building a PCH with modules enabled this import would assert in the
ASTWriter and (if assertions were disabled) sometimes crash the compiler
that loaded the resulting PCH when trying to lookup the submodule ID.
rdar://problem/24137448
llvm-svn: 259859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per review feedback the name was wrong and it can be used outside
Objective-C.
Unfortunately, making the internal struct visible broke some ASTMatchers
tests that assumed that the first record decl would be from user code,
rather than a builtin type. I'm worried that this will also affect
users' code. So this patch adds a typedef to wrap the internal struct
and only makes the typedef visible to namelookup. This is sufficient to
allow the ASTReader to merge the decls we need without making the struct
itself visible.
rdar://problem/24425801
llvm-svn: 259734
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original message:
Make CF constant string decl visible to name lookup to fix module errors
The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.
Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type. This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.
Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.
Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.
rdar://problem/24425801
llvm-svn: 259721
|
|
|
|
|
|
|
|
|
| |
module errors.
This breaks some internal bots in stage2: clang seg fault.
Looking with Ben to see what is going on.
llvm-svn: 259715
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.
Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type. This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.
Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.
Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.
rdar://problem/24425801
llvm-svn: 259624
|
|
|
|
|
|
|
| |
Patch by Vassil Vassilev!
Reviewed by Richard Smith.
llvm-svn: 258524
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
can be found in a module.
There are externally visible anonymous types that can be found:
typedef struct { } s; // I can be found via the typedef.
There are anonymous internal types that can be found:
namespace { struct s {}; } // I can be found by name.
rdar://problem/24199640
llvm-svn: 258272
|
|
|
|
|
|
| |
rdar://problem/24199640
llvm-svn: 258252
|
|
|
|
|
|
|
|
|
| |
variables are visited.
This shouldn't encourage anyone to put global variables into clang modules.
rdar://problem/24199640
llvm-svn: 258250
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
until we are visiting their declcontext.
This fixes a regression introduced in r256962:
When building debug info for a typdef'd anonymous tag type, we would be
visiting the inner anonymous type first thus creating a "typedef changes
linkage of anonymous type, but linkage was already computed" error.
rdar://problem/24199640
llvm-svn: 258152
|
|
|
|
|
|
| |
equivalent internal linkage entities.
llvm-svn: 257512
|
|
|
|
| |
llvm-svn: 257241
|
|
|
|
|
|
|
|
|
|
| |
building a module. Prior to this change, the private header's content would
only be included if the header were included by another header in the same
module. If not (if the private header is only used by the .cc files of the
module, or is included from outside the module via -Wno-private-header),
a #include of that file would be silently ignored.
llvm-svn: 257222
|
|
|
|
| |
llvm-svn: 256963
|
|
|
|
|
|
|
|
|
| |
was visited and all decls have been merged.
We only get a single chance to emit the types for virtual classes because
CGDebugInfo::completeRequiredType() categorically doesn't complete them.
llvm-svn: 256962
|
|
|
|
|
|
|
|
|
| |
have a nested name specifier. Strictly speaking, forward declarations of class
template partial specializations are not permitted at all, but that seems like
an obvious wording defect, and if we allow them without a nested name specifier
we should also allow them with a nested name specifier.
llvm-svn: 255383
|
|
|
|
|
|
|
|
|
| |
a hidden tag"
Now not trying to use a C++ lookup mechanism in C (d'oh). Unqualified
lookup is actually fine for this case in C.
llvm-svn: 255377
|
|
|
|
|
|
|
|
|
|
| |
a hidden tag"
This is causing assertion failures; reverting until I can fix.
This reverts commit r255267
llvm-svn: 255324
|
|
|
|
|
|
|
|
|
| |
This makes non-C++ languages find the same decl as C++ does to
workaround a regression introduced in r252960.
rdar://problem/23784203
llvm-svn: 255267
|
|
|
|
|
|
|
| |
declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
llvm-svn: 253283
|
|
|
|
|
|
|
|
|
| |
r233345 started being stricter about typedef names for linkage purposes
in non-visible modules, but broke languages without the ODR.
rdar://23527954
llvm-svn: 253123
|
|
|
|
|
|
|
|
|
|
| |
When linking against text-based dynamic library SDKs the library name of a
framework has now more than one possible filename extensions. This fix tests for
both possible extensions (none, and .tbd).
This fixes rdar://problem/20609975
llvm-svn: 253060
|
|
|
|
|
|
|
|
|
| |
the linkage of the enumeration. For enumerators of unnamed enumerations, extend
the -Wmodules-ambiguous-internal-linkage extension to allow selecting an
arbitrary enumerator (but only if they all have the same value, otherwise it's
ambiguous).
llvm-svn: 253010
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations in redeclaration lookup. A declaration is now visible to
lookup if:
* It is visible (not in a module, or in an imported module), or
* We're doing redeclaration lookup and it's externally-visible, or
* We're doing typo correction and looking for unimported decls.
We now support multiple modules having different internal-linkage or no-linkage
definitions of the same name for all entities, not just for functions,
variables, and some typedefs. As previously, if multiple such entities are
visible, any attempt to use them will result in an ambiguity error.
This patch fixes the linkage calculation for a number of entities where we
previously didn't need to get it right (using-declarations, namespace aliases,
and so on). It also classifies enumerators as always having no linkage, which
is a slight deviation from the C++ standard's definition, but not an observable
change outside modules (this change is being discussed on the -core reflector
currently).
This also removes the prior special case for tag lookup, which made some cases
of this work, but also led to bizarre, bogus "must use 'struct' to refer to type
'Foo' in this scope" diagnostics in C++.
llvm-svn: 252960
|
|
|
|
| |
llvm-svn: 252170
|