I discovered this when experimenting with `std::map::iterator`, which has a const overload of `operator*` that returns a non-const reference, and does not have a const overload of `operator*`.
rdar://112471779
C++ `T& operator*()` is mapped to a Swift computed property `var pointee: T`.
Previously `var pointee` only had a getter, after this change it will also have a setter if the C++ type declares an overload of `operator*` that returns a mutable reference.
rdar://112471779
This fixes linker errors when there are multiple instantiations of a templated struct with numeric template parameters.
When mangling the name of a C++ template specialization, we currently ignore non-type templated parameters. This causes two different instantiations of the same templated type to have the same mangled name, triggering linker errors.
rdar://107757051
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.
The `isBoolType` operation within the Clang importer has a historical
definition that excludes the C++ `bool` and its use in C as an
extension. Retain that definition, and check for the actual `bool`
when importing C++ conversion functions into Swift.
Fixes two regressions in the Clang importer:
1. We started to import `bool`-typed Objective-C properties with their
getter names.
2. We started importing `bool`-typed Objective-C methods with an
NSError** parameter as `throws`.
Both of these changes could be considered improvements, but they
cannot be made without breaking source compatibility, so roll those
changes back to maintain source compatibility.
We should have a separate discussion about enabling this behavior for
Swift >= 6.
Instead of mangling class template specializations with the prefix "__CxxTemplateInst," simply set the decl name as the class templates plus the types that it is specialized on (so `vector<Int>` rather than `__CxxTemplateInstNSt3__16vectorIi...`).
This is mainly to improve diagnostics. As a side effect of this change, if anyone copies the name of a class template specializaiton from an error/warning and uses it in source code, the compiler will error (that class templates aren't available in swift) rather than silently passing only to cause serailization failures down the road.
When importing a C++ struct that contains two methods that only differ in const-ness, we append `Mutating` to the name of the non-const method to make it possible to call from Swift unambiguously.
Unfortunately that logic was dependent on the order in which we import methods of a class: the `Mutating` suffix was added when another method with the same name was already imported.
This caused lookup failures, and the behavior was incorrect when the pair of methods return instances of an unsafe type: the const overload was renamed as `Unsafe` properly, but the non-const overload was not renamed.
Clang recently started wrapping more types in `clang::ElaboratedType` after this change: https://reviews.llvm.org/D112374
This broke some assumptions in ClangImporter, specifically in enum handling logic. This change adjusts those.
Fixes these tests in rebranch:
* `Interop/Cxx/enum/anonymous-with-swift-name-module-interface.swift`
* `Interop/Cxx/enum/anonymous-with-swift-name-objc-module-interface.swift`
* `Interop/Cxx/enum/anonymous-with-swift-name.swift`
* `Interop/Cxx/enum/c-enums-NS_OPTIONS-NS_REFINED_FOR_SWIFT.swift`
* `Interop/Cxx/enum/c-enums-NS_OPTIONS.swift`
* `Interop/Cxx/enum/c-enums-withOptions-omit.swift`
* `Interop/Cxx/class/inheritance/fields-module-interface.swift`
* `Interop/Cxx/class/inheritance/fields.swift`
* `Interop/Cxx/class/inheritance/functions-module-interface.swift`
* `Interop/Cxx/class/inheritance/sub-types-module-interface.swift`
* `Interop/Cxx/class/inheritance/type-aliases-module-interface.swift`
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
When an anonymous enum is imported, its imported name is under some
circumstances derived from the type that it is backed by.
NS_REFINED_FOR_SWIFT is a macro that produces a __attribute__((swift_private))
that when attached to a declaration, the imported name of this
declaration should have two underscores prepended. When the name
anonymous enum is derived from another declaration, and said declaration
does not have the same swift private attribute, the __ is dropped. This
patch fixes this.
This was discovered during interop adoption in SwiftCompilerSources.
```
/Volumes/Projects/swift/swift/include/swift/SIL/SILNode.h:180:5 <Spelling=/Volumes/Projects/swift/swift/include/swift/SIL/SILNode.h:171:3>: while adding SwiftName lookup table entries for clang declaration 'swift::SILNode::SharedUInt8Fields::(anonymous)'
```
C++ pre-increment operator `T& T::operator++()` is mapped into a non-mutating function `successor() -> Self`.
The naming matches existing functions for `UnsafePointer`/`UnsafeMutablePointer`.
The purpose of this is to be used for iterator bridging: C++ requires iterators to define a pre-increment operator (https://en.cppreference.com/w/cpp/named_req/Iterator), which Swift will use to iterate over C++ sequences and collections.
When ClangImporter::Implementation::inferDefaultArgument processes
func/method arguments as part of omitNeedlessWordsInFunctionName it
processes information about how the typenames for the parameters related
to the parameter names to form a parameter names list. The parameter
names list is used to determine if the argument label for a function
should be clipped based on the typename. So for example a type like
NSOrderedCollectionDifferenceCalculationOptions would cause a label
ending with "Options" to get clipped so that for instance "withOptions"
becomes simply "with".
Unfortunately in the context of C++-Interop, the typename for the
parameter often resolves to what the type backing the typedef or enum is
and not the actual name of the typedef
(so `typedef NSUInteger NSOrderedCollectionDifferenceCalculationOptions`
resolves to a name of NSUInteger rather than
NSOrderedCollectionDifferenceCalculationOptions).
This patch seeks to collect a bit more information when processing
NS_OPTIONS typedefs and providing that to the calling
omitNeedlessWordsInFunctionName to handle more inteligently.
In practice this fixes anywhere in Foundatio where
`withOptions: NSOrderedCollectionDifferenceCalculationOptions` is used.
When constructing SwiftLookupTable at clang module creation time, calls
to `clang::Sema::LookupName` will fail in C++ mode (including ObjC++).
The specific reason is that `clangSema.TUScope` (which we are passing in
as a Scope) is `nullptr` as we have no active Parser. The C++ path in
`clang::Sema::LookupName` is set to fail early and hard when the Scope
passed in is nullptr. In most, if not all, calls to `LookupName`, we
care about ObjC symbols and not C++ names. For example, the motivation
behind this issue is that ObjC protocols are not being renamed when
there is an ObjC class with the same name, leading to compilation
failures.
The Clang Importer when C++ interop is not enabled, disambigate an Obj-C
class and protocol that are named the same by appending `Protocol` to
the protocol. This was not happening when C++ interop was enabled, but
should also apply to Obj-C++ modules.
The fix is providing an starting scope for the search, which the C++
name lookup need to actually find the similarly named counterpart.
Includes a test to avoid this problem creeping in again, and locally it
did not break any other tests.
If a method has an `async` variant, the non-`async` variant will now mark its completion handler parameter `@Sendable`. This shouldn't be a breaking change in Swift 5 code since these declarations are automatically `@_predatesConcurrency`.
Also adds:
• Support for `@_nonSendable` on parameters, which can be used to override this implicit `@Sendable`
• Support for `@Sendable` on block typedefs; it's generally going to be a good idea to mark completion block typedefs `@Sendable`.
Fixes rdar://85569247.
We missed a spot during name importing to check this flag.
Since we don't have a ClangImporter instance directly available,
just check the flag.
Fixes rdar://87718892.
This patch introduces new diagnostics to the ClangImporter to help
explain why certain C, Objective-C or C++ declarations fail to import
into Swift. This patch includes new diagnostics for the following entities:
- C functions
- C struct fields
- Macros
- Objective-C properties
- Objective-C methods
In particular, notes are attached to indicate when any of the above
entities fail to import as a result of refering an incomplete (only
forward declared) type.
The new diangostics are hidden behind two new flags, -enable-experimental-clang-importer-diagnostics
and -enable-experimental-eager-clang-module-diagnostics. The first flag emits diagnostics lazily,
while the second eagerly imports all declarations visible from loaded Clang modules. The first
flag is intended for day to day swiftc use, the second for module linting or debugging the importer.
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.
We need to delete the `MangleContext` after we create it. This follows the existing use of `ItaniumMangleContext::create` in ASTMangler.cpp and a similar change in llvm here: llvm/llvm-project/commit/8b5783194ced98cabaa585678cacaf7c2e2763d8
If possible, add imported members to the StructDecl's LookupTable rather than adding them directly as members. This will fix the issues with ordering that #39436 poorly attempted to solve during IRGen.
This also allows us to break out most of the test changes from #39436.
We allow import of non-prototyped blocks such as `void (^)()` and treat
them the same way as `void (^)(void)`, so do the same with `async` imports.
Fixes rdar://81239857.
