| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
emit lexical contents for a declaration for another module. Track which module
those contents came from, and ensure that we only grab the lexical contents
from a single such instantiation.
llvm-svn: 244682
|
|
|
|
| |
llvm-svn: 244410
|
|
|
|
|
|
|
|
| |
arguments because the reloaded form might have become non-canonical across the
serialization/deserialization step (this particularly happens when the
canonical form of the type involves an expression).
llvm-svn: 244409
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... and add aarch32 to specifically refer to the 32-bit ones.
Previously, 'arm' meant only 32-bit architectures and there was no way
for a module to build with both 32 and 64 bit ARM architectures.
Now a module that is intended to work on both architectures can specify
requires arm
whereas a module only for 32-bit platforms can say
requires aarch32
and just like before, 64-bit only can say
requires aarch64
llvm-svn: 244306
|
|
|
|
|
|
| |
the same anonymous union is defined across multiple modules.
llvm-svn: 243940
|
|
|
|
|
|
|
|
|
| |
-working-directory option is set, results in error.
The error was "module '<name>' was built in directory '<path>' but now resides in directory '<path>'
rdar://21330027
llvm-svn: 243718
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also fix completely broken and untested code which was hiding the
primary bug. The !LLVM_ON_UNIX branch of the ifdef was actually a no-op.
I ran into this in the wild. It was causing failures in our SDK build.
Ideally we'd have a perfect llvm::sys::fs::canonical, but at least this
is a step in the right direction, and fixes an obviously broken case.
In some sense the test case I've added here is an integration test. We
should have these routines thoroughly unit tested in llvm::sys::fs.
llvm-svn: 243597
|
|
|
|
|
|
|
|
|
|
| |
UsingShadowDecls over other declarations of the same entity in the lookup
results. This ensures that we build correct redeclaration chains for the
UsingShadowDecls (otherwise we could see assertions and other misbehavior in
modules builds, when merging combines multiple redeclaration chains for the
same entity from the same module into one chain).
llvm-svn: 243592
|
|
|
|
|
|
| |
when the template is declared in a namespace.
llvm-svn: 242653
|
|
|
|
| |
llvm-svn: 242109
|
|
|
|
|
|
| |
module' declarations, show how we got to that module map file.
llvm-svn: 242105
|
|
|
|
|
|
|
|
|
|
|
| |
And make the module unavailable without breaking any parent modules.
If there's a missing requirement after we've already seen a missing
header, still update the IsMissingRequiement bit correctly. Also,
diagnose missing requirements before missing headers, since the
existence of the header is moot if there are missing requirements.
llvm-svn: 242055
|
|
|
|
|
|
|
|
|
|
| |
visible in the module we're considering entering. Previously we assumed that if
we knew the include guard for a modular header, we'd already parsed it, but
that need not be the case if a header is present in the current module and one
of its dependencies; the result of getting this wrong was that the current
module's submodule for the header would end up empty.
llvm-svn: 241953
|
|
|
|
|
|
| |
for a header to work in the presence of module hierarchy.
llvm-svn: 241936
|
|
|
|
|
|
| |
underlying types. A visible declaration is enough to make the type complete, but not enough to make the definition visible.
llvm-svn: 241743
|
|
|
|
|
|
| |
empty namespace.
llvm-svn: 241732
|
|
|
|
|
|
|
| |
instantiation, use the set of modules visible from the template definition, not
from whichever declaration the specialization was instantiated from.
llvm-svn: 241662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use findModuleForHeader() in several places, but in header search we
were not calling it when a framework module didn't show up with the
expected name, which would then lead to unexpected non-modular includes.
Now we will find the module unconditionally for frameworks. For regular
frameworks, we use the spelling of the module name from the module map
file, and for inferred ones we use the canonical directory name.
In the future we might want to lock down framework modules sufficiently
that these name mismatches cannot happen.
rdar://problem/20465870
llvm-svn: 241258
|
|
|
|
|
|
|
| |
rarely matters, but can affect whether two dependent types are canonically
equivalent.
llvm-svn: 241207
|
|
|
|
|
|
|
| |
class template specialization visible just because the class template
specialization's definition is visible.
llvm-svn: 241182
|
|
|
|
|
|
| |
parse-merging.
llvm-svn: 241180
|
|
|
|
|
|
| |
any source of the inline nature is sufficient.
llvm-svn: 241146
|
|
|
|
|
|
|
|
|
|
|
| |
update the identifier in case we've imported a definition of the macro (and
thus the contents of the header) from a module.
Also fold ExternalIdentifierLookup into ExternalPreprocessorSource; it no longer
makes sense to keep these separate now that the only user of the former also
needs the latter.
llvm-svn: 241137
|
|
|
|
|
|
|
| |
local submodule visibility enabled; that top-level file might not actually be
the module includes buffer if use of prebuilt modules is disabled.
llvm-svn: 241120
|
|
|
|
|
|
|
|
|
| |
This allows a module-aware debugger such as LLDB to import the currently
visible modules before dropping into the expression evaluator.
rdar://problem/20965932
llvm-svn: 241084
|
|
|
|
|
|
|
|
| |
For r240967.
rdar://problem/21512307
llvm-svn: 240968
|
|
|
|
|
|
| |
parsing then merged again when the module was loaded.
llvm-svn: 240700
|
|
|
|
|
|
|
| |
file in the loaded module maps and one of them is from the current module,
that's the right match.
llvm-svn: 240350
|
|
|
|
|
|
| |
all modules even if we've already found a definition that's not visible.
llvm-svn: 240204
|
|
|
|
| |
llvm-svn: 239954
|
|
|
|
|
|
|
|
|
| |
Previously we'd complain about redefinition of default arguments when we
instantiated a class with a friend template that inherits its default argument,
because we propagate the default template arguemnt onto the friend when we
reload the AST.
llvm-svn: 239857
|
|
|
|
|
|
| |
would collide
llvm-svn: 239765
|
|
|
|
|
|
|
| |
Support this across module save/reload and extend the 'missing import'
diagnostics with a list of providing modules.
llvm-svn: 239750
|
|
|
|
| |
llvm-svn: 239578
|
|
|
|
| |
llvm-svn: 239575
|
|
|
|
|
|
| |
with a base-specifier inside a namespace.
llvm-svn: 239569
|
|
|
|
|
|
| |
disabled but local module visibilty was enabled.
llvm-svn: 239504
|
|
|
|
| |
llvm-svn: 239487
|
|
|
|
|
|
|
| |
modules, and allow use of a default template argument if any of the parameters
providing it is visible.
llvm-svn: 239485
|
|
|
|
| |
llvm-svn: 239452
|
|
|
|
|
|
|
| |
This is just a preparatory step towards fixing visibility for default template
arguments in modules builds.
llvm-svn: 239447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are still problems here, but this is a better starting point.
The main part of the change is: when doing a lookup that would accept visible
or hidden declarations, prefer to produce the latest visible declaration if
there are any visible declarations, rather than always producing the latest
declaration.
Thus, when we inherit default arguments (and other properties) from a previous
declaration, we inherit them from the previous visible declaration; if the
previous declaration is hidden, we already suppress inheritance of default
arguments.
There are a couple of other changes here that fix latent bugs exposed by this
change.
llvm-svn: 239371
|
|
|
|
|
|
|
|
|
|
| |
visibility is enabled) or leave and re-enter it, restore the macro and module
visibility state from last time we were in that submodule.
This allows mutually-#including header files to stand a chance at being
modularized with local visibility enabled.
llvm-svn: 237871
|
|
|
|
|
|
| |
one for non-type and template template parameters too.
llvm-svn: 237815
|
|
|
|
|
|
| |
an imported but hidden one.
llvm-svn: 237814
|
|
|
|
|
|
| |
a class template into an imported but hidden definition.
llvm-svn: 237647
|
|
|
|
|
|
| |
definition into an imported but hidden definition.
llvm-svn: 237612
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
llvm-svn: 237473
|
|
|
|
|
|
| |
imported but not visible definition.
llvm-svn: 236690
|
|
|
|
|
|
|
|
| |
should not export the macro.
... at least, not unless we have local submodule visibility enabled.
llvm-svn: 236369
|