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.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
* Pack the bits for IfConfigDecls into Decl
* Don't open symbols into a module when evaluating canImport statements
The module loaders now have API to check whether a given module can be
imported without importing the referenced module. This provides a
significant speed boost to condition resolution and no longer
introduces symbols from the referenced module into the current context
without the user explicitly requesting it.
The definition of ‘canImport’ does not necessarily mean that a full
import without error is possible, merely that the path to the import is
visible to the compiler and the module is loadable in some form or
another.
Note that this means this check is insufficient to guarantee that you
are on one platform or another. For those kinds of checks, use
‘os(OSNAME)’.
No functionality change. This goes all the way back to when we used to
set up the importer using clang -cc1 arguments instead of driver
(GCC-like) arguments.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
Remove all occurrences of a "useSwift2Name" bool, and replace it with
version plumbing. This means that ImportDecl is now entirely
version-based, and the importer Impl knows versions. This will be
needed for marking Swift 3 names as deprecated, when there is a new
Swift 4 name.
NFC.
ImportDecl has an alternate decl quasi-escape-hatch where it can
create alternative declarations for the same original Clang node. But,
it was limited at one, which worked accidentally in the case of
VisitObjCMethodDecl's attempts at importing a factory-init-suppressed
root-class method that points to the imported-as-init Swift
declaration.
This commit changes that to a TinyPtrVector, to support the upcoming
occasional case where we have more.
Swift side of this new flag. This allows Objective-C framework authors
to replace a pair of methods by properties without breaking source
compatibility. This is especially important for class properties,
which were only introduced last year.
Still to come: importing the accessors even when this flag isn't set,
in order to provide better QoI when migrating from a method interface
to a property interface.
Part of rdar://problem/28455962
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
