...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`
getModuleHash in clang now takes a diagnostic engine to get more
information for uniquing the hash - this change was only needed
for swift-4.0-branch, so we're making the API adjustment here.
rdar://problem/32145037
For the multiple-files mode -emit-pch is still invoked in separate frontend invocation but with using a persistent PCH.
Subsequent frontend invocations use the persistent PCH but they don't need to validate it.
For all-files mode (e.g. WMO) the frontend invocation uses a persistent PCH that it also validates.
