When -fmodule-format is set to "obj", emit debug info for all types
declared in a module or referenced by a declaration into the module's
object file container.
This patch adds support for Objective-C types and methods.
llvm-svn: 247068
When -fmodule-format is set to "obj", emit debug info for all types
declared in a module or referenced by a declaration into the module's
object file container.
This patch adds support for C and C++ types.
llvm-svn: 247049
context is the class itself but lookups should be performed starting with the
lookup parent of the class (class and base members don't shadow types from the
surrounding context because they have not been declared yet).
llvm-svn: 245236
Summary:
If a module was unavailable (either a missing requirement on the module
being imported, or a missing file anywhere in the top-level module (and
not dominated by an unsatisfied `requires`)), we would silently treat
inclusions as textual. This would cause all manner of crazy and
confusing errors (and would also silently "work" sometimes, making the
problem difficult to track down).
I'm really not a fan of the `M->isAvailable(getLangOpts(), getTargetInfo(),
Requirement, MissingHeader)` function; it seems to do too many things at
once, but for now I've done things in a sort of awkward way.
The changes to test/Modules/Inputs/declare-use/module.map
were necessitated because the thing that was meant to be tested there
(introduced in r197805) was predicated on silently falling back to textual
inclusion, which we no longer do.
The changes to test/Modules/Inputs/macro-reexport/module.modulemap
are just an overlooked missing header that seems to have been missing since
this code was committed (r213922), which is now caught.
Reviewers: rsmith, benlangmuir, djasper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10423
llvm-svn: 245228
This preserves backwards compatibility for two hacks in the Darwin
system module map files:
1. The use of 'requires excluded' to make headers non-modular, which
should really be mapped to 'textual' now that we have this feature.
2. Silently removes a bogus cplusplus requirement from IOKit.avc.
Once we start diagnosing missing requirements and headers on
auto-imports these would have broken compatibility with existing Darwin
SDKs.
llvm-svn: 244912
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
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
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
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
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
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
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
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
Adrian Prantl