This adds support for `swift_name` attribute being used with C++ types that are declared within namespaces, e.g.
```
__attribute__((swift_name("MyNamespace.MyType.my_method()")))
```
Previously import-as-member would only accept a top-level unqualified type name.
rdar://138934888
Partially revert https://github.com/swiftlang/swift/pull/80035 now that Clang
has its own APIs for querying serialized modules for the decl representing the
availability domain with a given name.
In addition to tracking availability domains in SwiftLookupTable, also
serialize and deserialize the mapping from domain name to `clang::VarDecl`.
Ideally this serialization and lookup infrastructure would be entirely handled
by Clang, since it also needs to look up availability domains in serialized
modules, but the implementation for that is not ready yet.
Part of rdar://138441266.
This is very brittle in this first iteration. For now we require the
declaration representing the availability domain be deserialized before it can
be looked up by name since Clang does not have a lookup table for availabilty
domains in its module representation. As a result, it only works for bridging
headers that are not precompiled.
Part of rdar://138441266.
Conflicts:
- `include/swift/Localization/LocalizationFormat.h`
- `lib/ClangImporter/SwiftLookupTable.cpp`
- `lib/ClangImporter/SwiftLookupTable.h`
- `lib/Serialization/ModuleFormat.h`
- `lib/Serialization/Serialization.cpp`
All from the hash changes being added to main. Took main except for the
lookup table minor version, which needs to be bumped still because of
other changes.
Several serialization IDs that used to be 32 bits are being widened to 64. Modify SwiftLookupTable and its supporting types to accommodate this.
The new design uses a 64-bit integer for the pointer, decl, macro, or identifier ID, plus a 32-bit integer for the submodule ID (this field is set to all ones to indicate a decl vs. a macro). An additional in-memory bool distinguishes pointer nodes from ID nodes. Advantages:
• The main ID is now 64 bits wide, accommodating recent changes in clang.
• We’re no longer stealing bits from clang (we *do* steal the max value of the submodule ID, though).
• There’s no on-disk bit that, when set, will cause an ID to be interpreted as a pointer.
• Design is robust against `clang::serialization::SubmoduleID` also becoming 64-bit (although this will waste space).
Fixes rdar://131134424.
The only caller is `loadNamedMembers`, and that
passes in a non-optional EffectiveClangContext,
meaning that we'd miss the case when
`getEffectiveClangContext` returns `nullptr`, crashing
in `translateContext`. No test case unfortunately
as I haven't been able to come up with a reproducer.
rdar://129619711
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
When the ClangImporter imports a name, it associates it with a
an EffectiveClangContext. An EffectiveClangContext can be thought of
as the Clang scope the declaration will reside in, as far as importing
into Swift is concerned. This helps API notes and NS_SWIFT_NAME
to manipulate the SDK interface presented to Swift users.
When a entry is added to the Swift lookup table, it is associated
with a context. This context is a type and a name, used to effectively
namespace entries in the table. This context is derived from the
EffectiveClangContext associated with the name. This translation is
handled by SwiftLookupTable::translateContextDecl among other machinery.
This method in particular, understands only how to translate a set of
Clang nodes, and fails to create a context in other cases.
Prior to this patch, the EffectiveClangContext of declarations annotated
with UIKIT_EXTERN, with cxx-interop turned on, was a LinkageSpecDecl.
This results in context translation failure, and warnings produced in
SwiftLookupTable::finalizeLookupTable. This patch corrects name import
behavior to skip over the LinkageSpecDecl, and use the enclosing
TranslationUnit instead. This is appropriate and performed by
`determineEffectiveContext` as a LinkageSpecDecl is a so called
"transparent" context. That is its members are semantically declared and
accessible outside the context without additional qualification.
This patch tests using API notes, as that is the method UIKit uses. The
issue could just as easily be surface with a NS_SWIFT_NAME annotation.
Even without any annotation at all, the we would still fail to
translate, though there would likely be no corresponding warnings.
This patch fixes an issue with C++-Interop that has been making it so
that enums under interop were not getting properly looked up and
therefore not getting imported. The reason for this was that the proper
DeclContext was not getting applied when grabbing the decls use by
VisitDecls later in the ClangImporter.
The lookup code at SwiftLookupTable::lookup is given a clang TU which is
what implcitly gets turned into an EffectiveClangContext. The
EffectiveClangContext is the piece that decides which DeclContext to
use. In the case of an extern "C" (ie LinkageSpecDecl), the
EffectiveClangContext was not traversing inside the lexical scope of the
extern "C" as the context for searching the EnumDecl (the NS_OPTIONS
Enum).
This patch adds new behavior when EffectiveClangContext is given a
LinkageSpecDecl. It sets the DeclContext to the lexical decl context.
With this fix in place in the presence of C++-Interop we not only import
the NS_OPTIONS typedef properly, but we also import the enum (and
therefore the EnumConstants) correctly (which are used for getting to
the flags for populating the NS_OPTIONS bitfields.
Previously a namespace declaration was imported along with all of its redeclarations, and their members were added to a single Swift extension. This was problematic when a single namespace is declared in multiple modules – the extension belonged to only one of them.
For an example of this, try printing a module interface for `std.string`/`std.iosfwd` – it will be empty, even though the declarations from those modules are actually imported into Swift correctly.
This change makes sure that when we're importing different redeclarations of the same namespace, we're adding them as separate extensions to appropriate modules.
This adds support to `ClangImporter` to import C++ member function operators as static methods into Swift, which is part of SR-12748.
The left-hand-side operand, which gets passed as the `this` pointer to the C++ function is represented as an additional first parameter in the Swift method. It gets mapped back in SILGen.
Two of the tests are disabled on Windows because we can't yet call member functions correctly on Windows (SR-13129).
Lazy member loading had an antagonistic relationship with the import-as-member facilities. The member tables were stored in a hash map that is keyed by serialized declaration context. While this was good for importing the entire member set of a given extension, it's in the complete wrong order for lazy member loading, which wants the same data keyed by base name.
Given that it is annoying to redo the globals-as-member tables to support one use case or the other, coupled with the fact that optimizing for one use-case automatically pessimizes the other, just take a page from rdar://18696086 and store the same information twice in two separate formats each optimized for the task at hand.
Preliminary benchmarks indicate that this leads to a 5% reduction in Clang-Imported entities which will drastically speed up most apps that use Dispatch and CoreGraphics.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
1. Set the diagnostic location to where the attribute was written (or
to the Clang decl's source, if the attribute came from API notes)
2. Add a note to contact the owners of the framework to make it clear
that the client of the framework didn't do anything wrong.
rdar://problem/52736145
PointerUnion was generalized to be variadic. Replaced uses of
PointerUnion3 with PointerUnion
See also: git-svn-id:
https://llvm.org/svn/llvm-project/llvm/trunk@360962
91177308-0d34-0410-b5e6-96231b3b80d8
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
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.
Also lays the groundwork for rdar://problem/16513537, which is about
being able to find an enum by its original top-level name so that we
can show a diagnostic for that. I'll file a public bug about that
later.
rdar://problem/31893305
Shave off a pointer from the EffectiveClangContext, by re-arranging
some of its data. Down to 2 pointers from 3.
Inside of ImportName, factor out the does-it-have-a-value from
multiple stored Optionals so as to shave off a couple of
pointers. Present the same programming interface as before. Down to 8
pointers in size from 10, and still much further to go.
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.
...instead of picking one definition arbitrarily. This comes from the
new "lookup table" design in Swift 3---we no longer just look for any
"visible" (imported) macro definition, but instead need to know them
up front. This works fine when there's only one definition per module,
but for modules like 'OpenGL' on macOS, with mutually-exclusive
submodules 'GL' and 'GL3', the compiler was arbitrarily deciding that
all of the macros the submodules had in common belonged to 'GL'.
The new model tries to decide if it's possible for two modules to be
imported separately, and keeps both macro entries if possible, only
deduplicating equivalent definitions at the last minute (when
importing into Swift). This /still/ doesn't perfectly match the
behavior you'd get in C, where a submodule and its parent module could
theoretically have conflicting definitions and you'd be fine as long
as you only imported one of them, but hopefully (a) it's close enough,
and (b) nobody is doing that. (The Swift compiler will prefer the
definition in the parent module even if the submodule is the only one
imported.)
rdar://problem/26731529
When attempting to compile Swift 2 code (or any Swift code using the
Swift 2 names) in Swift 3, the compiler diagnostics are often entirely
useless because the names have changed radically enough that one
generally gets "no member named 'foo'" errors rather than a helpful
"'foo' was renamed to 'bar'" error. This makes for a very poor user
experience when (e.g.) trying to move Swift 2 code forward to Swift 3.
To improve the experience, when the Swift 2 and Swift 3 names of an
API differ, the Clang importer will produce a "stub" declaration that
matches the Swift 2 API. That stub will be marked with a synthesized
attribute
@available(unavailable, renamed: "the-swift-3-name")
that enables better diagnostics (e.g., "'foo' is unavailable: renamed
to 'bar') along with Fix-Its (courtesy of @jrose-apple's recent work)
that fix the Swift 2 code to compile in Swift 3.
This change addresses much of rdar://problem/25309323 (concerning QoI
of Swift 2 code compiled with a Swift 3 compiler), but some cleanup
remains.
