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.
Clang now accepts an option -fapinotes-swift-version=XX that describes
which Swift version to use when applying API notes to the Clang
AST. Pass this option down to Clang based on the Swift major version
number (e.g., 3 or 4), allowing API notes to introduce
Swift-version-specific behavior.
Fixes rdar://problem/28617631.
Drop the ImportNameSwiftContext, which was merely used to pass around
some global state. Instead, pass the relevant parts
directly. Additionally, remove the 2-phase initialization of a
NameImporter from the module writers, as they are only invoked once
per Clang instance anyways, we can hold a local instance. Also
streamlines some APIs.
NFC
During normal import, the name for a foreign entity may be requested
many times. As we have more and more complex logic to compute these
new names, the overhead of potential re-computations adds up. This
cache is hit about 1/3rd of the time when running a simple
CoreGraphics test case.
NFC
Banish the abomination that is clangSemaOverride, a previously
necessary evil. When building the module caches, different Clang
instances will be spawned than the one used by the normal
importer. Since we want to reuse code and get the same name both ways,
this meant threading through alternative clang Semas and preprocessors
throughtout, some of the time. This broke the abstraction and
encapsulation of the Impl, complicated the programming model, and
otherwise made effective caching hard.
Now that we’ve done enough ImportName refactoring, we can create a
NameImporter per Clang instance, and encapsulate naming therein. We
can now remove the sema overrides, as we have already done to the
preprocessor overrides.
This shifts the 2-phase initialization problem to the Impl and the
Clang module writers.
NFC
Delay initialization of the EnumInfoCache until a Clang instance is
ready, simplifying its interface and allowing us to finally make this
per-Clang-instance. This will allow us to further de-couple ImportName
from the importer imply, as well as allow us to use a more efficient
and simpler caching mechanism. It is now owned by the NameImporter.
NFC.
Move SwiftLookupTableReader/Writer into .cpp file, as they are
irrelevant to the rest of the importer, and this allows us to make
them more ImportName aware in the future. Pull more code out of
ClangImporter.cpp.
NFC.
SwiftNameLookupExtension and ClangImporter::Implementation were
friends, but as time goes on they have drifted apart. As part of the
ImportName refactoring, these are being decoupled to facilitate
multiple-name importing, and fight the existing false encapsulation
present in the Impl.
SwiftNameLookupExtension is now spun off into its own entity, and can
evolve to have and use its own de-coupled NameImporter.
Finally, SwiftNameLookupExtension no longer stors a reference to
ClangImporter::Implementation, a false encapsulation. Instead, it uses
a NameImporter of its own, and merely keeps a reference to the lookup
table map.
Future directions include making the NameImporter specific to a Clang
instance, meaning that we can effectively cache Clang entities better
(and not resort to EnumInfoCache's stringly keyed caches). We can also
then drop all notions of a "ClangOverride" and other messy phase
entanglement.
NFC
Change more methods on the Impl to be static, passing down an
ASTContext if necessary. While this does ugly up the functions
slightly with the extra parameter, it decouples them from the Impl,
which has been a false abstraction when building the lookup
tables. These can all be moved to a more appropriate place in the
future.
NFC
addEntryToLookupTable is one of the laggards holding back the
Impl-free Clang lookup table effort. Make a static variant, now that
we have the convenient NameImporter.
NFC
Name Importer wraps references to the Swift context and other needed
encapsulation. The eventual goal is to allow name lookup tables to
live separately from the Impl, and do better Clang-instance-based
caching in the future, as well as general separation of concerns.
NFC
Enable newly-introduced Clang functionality to load API notes stored
alongside the headers for a module or, for a framework, in an APINotes
subdirectory within the framework. Fixes rdar://problem/28455644.
This flag switches the "effective language version" of the compiler,
at least to any version supported (as of this change: "3" or "3.0").
At the moment nothing uses it except the language version build
configuration statements (#if swift(...)) and various other places
that report, encode, or otherwise check version numbers.
In the future, it's intended as scaffolding for backwards compatibility.
Fixes SR-2582
By refactoring out PlatformAvailability from the ClangImporter, we can
more easily refactor out isUnavailableInSwift from the impl, which
will free us up to do more flexible import naming.
Introduces new files ClangAdapter.h/cpp, which will serve as a
convenient place to put code reasoning about Clang details. Refactors
out most Clang-related is*, has*, and get* methods from the
ImporterImpl. In the future, an adapter class could help serve to
seperate the concerns of the importer from the details of how to
correctly use Clang APIs.
Refactors much of the import name determination from ClangImporter.cpp
into ImportName.cpp.
This is not a perfect separation, but it's a step in the right
direction. Long term, we'd like to get as much functionality off of
the ClangImporter::Implementation class and onto more specialized and
seperable (and stateless!) components.
