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
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
LLVM is gearing up to move to `std::endianness` and as part of that has
moved `llvm::support::endianness` to `llvm::endianness`
(bbdbcd83e6702f314d147a680247058a899ba261). Rename our uses.
Previously, `friend` operators declared in C++ classes were added to the lookup table when the class is being imported.
The operators were added to the wrong lookup table if the class is declared in a C++ namespace. Since a namespace can span across multiple Clang modules, its contents should be added to a translation unit level lookup table, not to a module level lookup table.
This change makes sure we add `friend` operators to the lookup table earlier, when we are actually building the lookup table. Note that this is not possible for class template instantiations, because those are instantiated later, so for templates we still handle `friend` operators when importing the instantiation.
rdar://116349899
If a C++ type `Derived` inherits from `Base` privately, the public methods from `Base` should not be callable on an instance of `Derived`. However, C++ supports exposing such methods via a using declaration: `using MyPrivateBase::myPublicMethod;`.
MSVC started using this feature for `std::optional` which means Swift doesn't correctly import `var pointee: Pointee` for instantiations of `std::optional` on Windows. This prevents the automatic conformance to `CxxOptional` from being synthesized.
rdar://114282353 / resolves https://github.com/apple/swift/issues/68068
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
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.
This applies the same trick as https://github.com/apple/swift/pull/62190 for newly written code.
Fixes two C++ interop tests in rebranch:
* `Interop/Cxx/enum/c-enums-NS_OPTIONS-api-notes-renamed-options.swift`
* `Interop/Cxx/enum/c-enums-NS_OPTIONS-swift-named-options.swift`
rdar://102858524
Prior to this patch, SwiftLookupTable::translateDeclToContext relied
on the `TypedefNameDeclOrQualifier` field of an anonymous tag decl to
create a name for entry representing an anonymous tag in the lookup
table. This field is not always populated by Clang, it is often
populated only for the purposes of generating a linkage name when the
type is introduced via typedef as follows:
```
typedef enum { option1, option2} MyAnonEnum;
```
The field is not populated for anonymous enums introduced by NS_OPTIONS
with cxx interop enabled. This patch adds a fallback check in
`translateDeclToContext` that if the field is empty, check if the enum
is backed by a typedef that is unavailable in Swift. If that is the
case, use that name for the lookup table entry.
Typedef-ed template types are now added to the lookup table in `addEntryToLookupTable`, there is no need to duplicate this logic in `populateTableWithDecl`.
When ClangImporter calls Clang to import a module, Clang calls `SwiftLookupTableWriter::writeExtensionContents` for each namespace redecl, which called `addEntryToLookupTable` (a few frames omitted) which iterated over all of the namespace redecls, doing duplicate work. This caused the complexity to degrade from linear to quadratic.
`SwiftDeclConverter::VisitNamespaceDecl` is still called once per namespace, not per redecl, so we need to iterate over all the redecls there.
This dramatically improves the build time for SwiftCompilerSources when importing Clang headers in addition to LLVM headers.
To fix a crash during deserialization, we need to store the mangled names of C++ class template instantiations in the lookup table.
For example, `std::string` will be serialized as `__CxxTemplateInstNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE`, and when another instance of the Swift compiler will later attempt to deserialize a decl referencing this instantiation, it will query the `SwiftLookupTable` for a decl with this name. If this instantiation is not referenced from the module that is currently being compiled, Swift will not instantiate `std::string` during typechecking, and the mangled name will be missing from `SwiftLookupTable`, leading to a deserialization failure. This happens when compiling with cross-module optimization enabled, and the current module does not reference `std::string`, but one of its dependencies does.
Make sure nested namespaces are added to the SwiftLookupTable when they are declared in a non-canonical redecl of the parent namespace.
This was blocking C++ interop adoption in SwiftCompilerSources.
This assertion assumes that only visibility directives for builtin-in
macros find their way here. However, the presence of textual headers
in modules means any macro directive can wind up here since clang will
report that it is currently not building a module.
It's been half a decade since this code did anything useful with
macro directives in textual headers, so just leave things be.
rdar://91768988
This cleans up 90 instances of this warning and reduces the build spew
when building on Linux. This helps identify actual issues when
building which can get lost in the stream of warning messages. It also
helps restore the ability to build the compiler with gcc.
llvm-project updated `hashExtension` in
655bea4226b401a11164f99c6344e38d8742b8e4 to use a `HashBuilder` rather
than `hash_code`. Update use in ClangImporter.
When apple/swift#39664 moved the logic for generating anonymous fields' names from ImportDecl to ImportName, it inadvertently replaced a check that the decl was *precisely* `clang::FieldDecl` with a check that it was `FieldDecl` *or a subclass*. This could cause a crash when it tried to call `FieldDecl::getFieldIndex()`, which doesn't work properly on instance variables even though `ObjCIvarDecl` is a subclass of `FieldDecl`. The easiest way to reproduce this is to use a bit field in a class's instance variables, since clang inserts an anonymous instance variable after it for padding.
This commit adds a test of a bit field instance variable and fixes the bug. It also adds a PrettyStackTrace frame in the Swift lookup table preparation code, which should make other bugs like this easier to diagnose.
Fixes rdar://85173321.
A change in the new clang branch seems to have caused it to start applying SwiftNameAttrs to forward declarations. We have apparently always tried to add these forward declarations to the lookup tables in PCH files, but never diagnosed the resulting failures because they did not have SwiftNameAttrs. Now they do, so we started emitting incorrect warnings.
We *probably* don’t need to process these at all, but there’s a risk of unintended behavior changes from that; instead, this commit takes a conservative approach and simply suppresses the warnings like we always have.
Fixes rdar://74710976.
When a given Objective-C method has a completion handler parameter
with an appropriate signature, import that Objective-C method as
async. For example, consider the following CloudKit API:
- (void)fetchShareParticipantWithUserRecordID:(CKRecordID
*)userRecordID
completionHandler:(void (^)(CKShareParticipant * _Nullable shareParticipant, NSError * _Nullable error))completionHandler;
With the experimental concurrency model, this would import as:
func fetchShareParticipant(withUserRecordID userRecordID: CKRecord.ID) async throws -> CKShare.Participant?
The compiler will be responsible for turning the caller's continuation
into a block to pass along to the completion handler. When the error
parameter of the completion handler is non-null, the async call
will result in that error being thrown. Otherwise, the other arguments
passed to that completion handler will be returned as the result of
the async call.
async versions of methods are imported alongside their
completion-handler versions, to maintain source compatibility with
existing code that provides a completion handler.
Note that this only covers the Clang importer portion of this task.
This is a roll-forward of https://github.com/apple/swift/pull/32950, with explicit c++17 version removed from tests. This is not needed since C++17 is the default anyway.
--
In this PR we teach `ClangImporter` to import typedef statements with template instantiation as its underlying type.
```c++
template<class T>
struct MagicWrapper {
T t;
};
struct MagicNumber {};
typedef MagicWrapper<MagicNumber> WrappedMagicNumber;
```
will be made available in Swift as if `WrappedMagicNumber` is a regular struct.
In C++, multiple distinct typedeffed instantiations resolve to the same canonical type. We implement this by creating a hidden intermediate struct that typedef aliasses.
The struct is named as `__CxxTemplateInst` plus Itanium mangled type of the instantiation. For the example above the name of the hidden struct is `__CxxTemplateInst12MagicWrapperI11MagicNumberE`. Double underscore (denoting a reserved C++ identifier) is used to discourage direct usage. We chose Itanium mangling scheme because it produces valid Swift identifiers and covers all C++ edge cases.
Imported module interface of the example above:
```swift
struct __CxxTemplateInst12MagicWrapperI11MagicNumberE {
var t: MagicNumber
}
struct MagicNumber {}
typealias WrappedMagicNumber = __CxxTemplateInst12MagicWrapperI11MagicNumberE
```
We modified the `SwiftLookupTable` logic to show hidden structs in `swift_ide_test` for convenience.
Co-authored-by: Rosica Dejanovska <rosica@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Robert Widmann <devteam.codafi@gmail.com>
In this PR we teach `ClangImporter` to import typedef statements with template instantiation as its underlying type.
```c++
template<class T>
struct MagicWrapper {
T t;
};
struct MagicNumber {};
typedef MagicWrapper<MagicNumber> WrappedMagicNumber;
```
will be made available in Swift as if `WrappedMagicNumber` is a regular struct.
In C++, multiple distinct typedeffed instantiations resolve to the same canonical type. We implement this by creating a hidden intermediate struct that typedef aliasses.
The struct is named as `__CxxTemplateInst` plus Itanium mangled type of the instantiation. For the example above the name of the hidden struct is `__CxxTemplateInst12MagicWrapperI11MagicNumberE`. Double underscore (denoting a reserved C++ identifier) is used to discourage direct usage. We chose Itanium mangling scheme because it produces valid Swift identifiers and covers all C++ edge cases.
Imported module interface of the example above:
```swift
struct __CxxTemplateInst12MagicWrapperI11MagicNumberE {
var t: MagicNumber
}
struct MagicNumber {}
typealias WrappedMagicNumber = __CxxTemplateInst12MagicWrapperI11MagicNumberE
```
We modified the `SwiftLookupTable` logic to show hidden structs in `swift_ide_test` for convenience.
Resolves https://bugs.swift.org/browse/SR-12591.
Co-authored-by: Rosica Dejanovska <rosica@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Robert Widmann <devteam.codafi@gmail.com>
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).
This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
