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.
This means all cross-module references and all mangled names will
consistently use the Swift 4 name (the canonical type), no special
handling required.
The main thing we lose here is that the Swift 4 names of imported
types become usable in Swift 3 mode without any diagnostics, similar
to how most language features introduced in Swift 4 are available in
Swift 3 mode. It also implies that the Swift 4 name will show up in
demangled names.
rdar://problem/31616162
- Add CompilerInvocation::getPCHHash
This will be used when creating a unique filename for a persistent
precompiled bridging header.
- Automatically generate and use a precompiled briding header
When we're given both -import-objc-header and -pch-output-dir
arguments, we will try to:
- Validate what we think the PCH filename should be for the bridging
header, based on the Swift PCH hash and the clang module hash.
- If we're successful, we'll just use it.
- If it's out of date or something else is wrong, we'll try to
emit it.
- This gives us a single filename which we can `stat` to check for the
validity of our code completion cache, which is keyed off of module
name, module filename, and module file age.
- Cache code completion results from imported modules
If we just have a single .PCH file imported, we can use that file as
part of the key used to cache declarations in a module. Because
multiple files can contribute to the __ObjC module, we've always given
it the phony filename "<imports>", which never exists, so `stat`-ing it
always fails and we never cache declarations in it.
This is extremely problematic for projects with huge bridging headers.
In the case where we have a single PCH import, this can bring warm code
completion times down to about 500ms from over 2-3s, so it can provide a
nice performance win for IDEs.
- Add a new test that performs two code-completion requests with a bridging header.
- Add some -pch-output-dir flags to existing SourceKit tests that import a bridging
header.
rdar://problem/31198982
We synthesize fake source locations for module imports that come from
Swift code; these locations have to be both valid and distinct for
Clang to use. We've mostly been getting away with simply making fake
offsets from the main file, but after the offsets start exceeding the
size of the buffer they start pointing into some /other/ file, and
then if Clang's SourceManager tries to order those locations it gets
/very/ confused.
This commit fixes that by allocating a 256K buffer of zeros and using
offsets into that instead. The hope is that a read-only mmap'd buffer
of zeros that never gets read (except possibly to look for newlines)
will be cheap to allocate.
(Why not just make the main file buffer 256K? Because we actually try
to parse that, and there's really no reason for the lexer to go crawl
through that file eagerly.)
This test case isn't the best because it doesn't actually fail in the
old code, but if only the assertion was added we at least hit that.
I did verify with the reproducing project I have that we no longer
hit this issue.
rdar://problem/30924269
A more general solution to ae458a84ad: import all versions of a name
that are going to show up as members, ignore those that aren't.
Further work on <rdar://problem/29170671> Import APIs under their
Swift 3 names.
There is a subtle incompatibility between the way bridging headers handle
module imports and the way clang's normal module-loading works (as done
by -emit-pch in bridging PCH, in particular).
When importing a submodule, Swift implicitly imports its supermodule. This
is part of Swift's treatment of modules and fine, we're not changing it
here.
But if client code imports a submodule, then tries to use a type that is
only defined in its supermodule, not the submodule, this _should_ cause
a parse error (and does in clang alone, or when generating a PCH).
Unfortunately Swift's "implicit parent import" currently happens
eagerly, so the supermodule is imported and its type is defined as soon
as the submodule is imported, which in turn suppresses the error.
This in turn means that client code thinks their code "works" and then
"breaks" when they turn on bridging PCH. What _should_ happen here is
that the (actually broken) client code should not be accepted in the first
place, neither bridging PCH nor textual bridging-header import.
This commit merely changes textual bridging-header import from eager
import to deferred parent-import, like bridging PCH does. This reconciles
the difference in behaviour between the two, at the cost of a source-compat
break.
rdar://30615193
...and Swift 4 versions in Swift 3, and Swift 2 and "raw" versions in
both. This allows the compiler to produce sensible errors and fix-its
when someone uses the "wrong" name for an API. The diagnostics
certainly have room to improve, but at least the essentials are there.
Note that this commit only addresses /top-level/ decls, i.e. those
found by lookup into a module. We're still limited to producing all
members of a nominal type up front, so that'll require a slightly
different approach.
Part of rdar://problem/29170671
This has the effect of propagating the search path to the clang importer as '-iframework'.
It doesn't affect whether a swift module is treated as system or not, this can be done as follow-up enhancement.
Extensive cross-language tooling support needs to bridge decl names between two different languages more freely. This SourceKit request is designed to translate Objc names to Swift names and vice versa. Working similarly to cursor-info requisition, the name translation request requires a Swift reference to a Swift/Clang decl, and the preferred name to translate from, and language kind that the given name belongs to. If the translation succeeds, SourceKit service responds with the corresponding name than belongs to the other kind of language.
Newly introduced keys:
“key.namekind": “source.lang.name.kind.objc” | "source.lang.name.kind.swift"
“key.basename”: “name"
“key.argnames”: [“name"]
“key.selectorpieces”: [“name[:]"]
This commit only implements translation from Objc to Swift.
Previously it wouldn't run the verifier again if no new modules were
imported, even if more decls had been loaded since last time. This
likely only affects script-mode files (main.swift-like).
We're trying to get rid of implicit bridging-header imports, as a feature.
These are IMPORTED_HEADER blocks left in modules built with bridging
headers, that trigger re-importing the bridging header into any client
that imports the module.
As a half-way measure to deprecating them, we add a warning here that
triggers when an implicit bridging-header import occurs that is _not_
suppressed as redundant by clang.
