This includes 'LONG_MAX' in the Darwin module, which is defined by the
system and then immediately redefined by Clang's copy of limits.h.
The general strategy here is that if two definitions of a macro in the
same module are in separate explicit submodules, we need to keep track
of both of them, but if they're in the same explicit submodule then
one is probably deliberately redefining the other. This isn't fully
correct because one explicit submodule could include another explicit
submodule, but it's a good first approximation, which we can refine if
we come across problem cases in practice.
Swift /also/ has the ability to distinguish between ModuleA.MACRO and
ModuleB.MACRO if you've imported both modules, although there's an
issue that the two of them end up getting the same mangled name if you
try to use both in the same compilation unit. (Filed
rdar://problem/34968281.) That ability is preserved with this change.
All of this will likely change if/when we switch to Clang's "local
submodule visibility" mode, which is needed for the C++ Modules TS but
is also incompatible with Apple's SDKs at the moment. In that case,
macros in two separate explicit submodules will no longer have an
'override' relationship just because they're mentioned sequentially in
the module map.
rdar://problem/34413934
Besides saving some calls to stat(), this also causes problems when
the user specifies a search path that Clang already adds by default,
like $SDKROOT/Library/Frameworks/. Why? Because Swift adds its search
paths after Clang has already configured its defaults, but Clang
reconfigures its search paths from scratch when compiling a module to
a PCM file to cache. This led to system search paths being found
sooner in the primary Clang instance than in the PCM files, which in
turn resulted in the PCM files being considered out of date.
This isn't likely to affect people much in practice, but it's better
to get right. (We ran into this during Doug's experiments in making
/System/Library/PrivateFrameworks a default search path in Clang
r313317; turns out that's problematic for other reasons as well.)
rdar://problem/34664596
...so that we don't have to keep coming back to update it every major
release. And also so we can actually put methods on it instead of
using free functions.
No intended behavior change (yet).
forEachDistinctName might produce the same name for Swift 4 and Swift
5, but it's possible that for some reason the name will only work in
one mode or the other. In that case, even though we're trying the
"same" name again, we still want to invoke the callback once more.
Add a boolean return to the callback to support this.
Tests to come at the end of this patch series -- this shows up when in
Swift 3 mode and the canonical version for types is set to Swift 5.
A public C module can be expressed as the combination of several
private modules at build time, where that structure is "collapsed"
into a single public module for client use. In such cases, the symbols
associated with the public module can actually be seen as coming from
the private module (e.g. at the time the Swift overlay is built),
which fools our overlay-specific hacks. When a module states that it
is re-exported via another, public module, teach semantic analysis to
treat the entity "as if" it came from the re-exporting public module.
Part of rdar://problem/34438586.
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
In order to allow LLDB to debug an app as it was written (in theory),
we stuff a semi-preprocessed version of the bridging header into the
generated swiftmodule file, so that we can fall back on it if the
original bridging header is deleted. The specific functionality we
want is in Clang's -rewrite-includes option, but we need to write to
an in-memory buffer instead of a file.
The existing code took the meat of clang::RewriteIncludesAction and
recreated it manually. We got away with this in the past, but upstream
Clang has changed how clang::RewriteIncludesAction works, and now what
we were doing before results in the (unused) file output stream being
deallocated before the (also unused) buffering stream wrapped around
it. Rather than continue trying to half-use an existing Clang
FrontendAction, just make a new one that does the thing we want and
nothing else.
I'd like to revisit this whole idea in the future -- it doesn't
actually preserve debuggability in the case where the bridging header
may have changed, because we don't check for modifications in all the
things it includes. But for now this should preserve the existing
functionality.
rdar://problem/33693128
This avoids having to bring in all members (and extensions!) for an
outer type just to look up a nested type. In the test case attached
(reduced from the project in SR-5284), this actually led to a circular
dependency between deserialization and the importer, which resulted in
a compiler crash.
This is not a new problem, but it's more important with the release of
Swift 4, where a number of Apple SDK types are now newly imported as
member types. (The one in the original bug was
NSView.AutoresizingMask, formerly NSAutoresizingMaskOptions.) Since we
always use the Swift 4 name for cross-references, this affected
everyone, even those still compiling in Swift 3 mode.
https://bugs.swift.org/browse/SR-5284
Special DeclNames represent names that do not have an identifier in the
surface language. This implies serializing the information about whether
a name is special together with its identifier (if it is not special)
in both the module file and the swift lookup table.
Clang's equivalent of this is mapping fatal errors to non-fatal errors.
This isn't something we really care about for users since it's so rare,
but we do use it in our tests, like this one that's been disabled for
a long time.
rdar://problem/30287833
Ever since we stopped associating the top-level struct of an imported
NS_ERROR_ENUM with the Clang enum declaration, we've been unable to
print imported NS_ERROR_ENUMs. The module-printing infrastructure
would drop them thinking they aren't imported declarations.
This also affected NS_ERROR_ENUMs that were imported as members of
another type, as well as other types imported as members.
Fixes rdar://problem/32497693.
Avoids a bogus "argument unused" warning, since bitcode compilation
doesn't bother to set up much of a Clang AST context. (-embed-bitcode
compiles in two steps: source -> bitcode, then bitcode -> object
file. This is about the second step.)
Patch by Bob Wilson, who's currently on vacation but wanted this to
get in sooner rather than later.
rdar://problem/31372950
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
