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)'
```
Calling `StructDecl::lookupDirect` with an operator identifier (e.g. `==`) previously returned no results. This happened because the underlying C++ operator function was added to the lookup table with an underscored name (e.g. `__operatorEqualEqual`), and the synthesized function was not added to the lookup table at all. Lookup should find the synthesized decl, since that is what Swift code will call.
This fixes a typechecker error when trying to conform a C++ struct that defines an operator to a Swift protocol with an operator requirement (e.g. `Equatable`).
If the IR representation of a C++ function takes an `SRet` parameter instead of a return value, Swift needs to wrap the corresponding argument with `sret(...)` on call site.
This fixes SILOptimizer crashes on arm64.
rdar://92963081
Restructure the `visualc` module into `vcruntime` in order to help
expose the various components (SAL, vcruntime, ucrt, corecrt, STL) for C++
modularization. Include the `stdint.h` textually to deal with
redefinition of types in clang resources and MSVC.
If a C++ method returns a pointer and is not annotated with `returns_nonnull`, ClangImporter imports its return type as implicitly unwrapped optional `UnsafePointer<T>!`. This happens, for example, for `begin()`/`end()` methods of C++ collection types.
We would like to be able to conform C++ collections to `Swift.Sequence`/`Swift.Collection`/... To make this work, we create Swift protocols that require `func begin() -> RawIterator` and `func end() -> RawIterator` where `RawIterator` is an associated type.
The problem is that currently if `RawIterator` is `UnsafePointer<T>?`, `begin()`/`end()` methods that return an implicitly unwrapped optional `UnsafePointer<T>!` won't satisfy the requirements. This change fixes that.
Due to a now default-enabled `undef` pass (llvm/llvm-project
1b1c8d83d3567a60280291c0adb95d1d60335509), a whole bunch of interop
IRGen tests are failing due to missing `undefs`, even though they don't
matter in these tests at all. Add regex matches so that these tests just
check for the name and types of the functions they care about.
Temporarily disable the checks for mutable fields in a C++ struct. A better solution would be to use some heuristic to detect if a method mutates a mutable field, and allow the user to adjust mutability with the existing `nonmutating` annotation.
rdar://92621793
Previously, the clang importer marked all const methods as mutating whenever a C++ record had mutable fields. This change allows overriding this behavior by using the "nonmutating" swift_attr attribute.
Fixes SR-15907.
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.
When we look up a name directly, make sure we provide a scope, this is required when C++ interop is enabled.
This issue was exposed when we look up if an NSString is hashable. There is a special case for classes that inherit from NSObject, but we didn't see that, because we couldn't find NSObject (because lookup failed).
This addresses SR-15272.
When you have a function (e.g. 'foo') which is used in a constructor
initializer (e.g. constructor of some class 'Bar'), and you use the
constructor from swift code without directly using the function (e.g.
Bar's ctor is used from swift but foo isn't, foo is used from Bar's ctor),
you will get a link error. My fix is as follows:
When walking the clangAST to be imported, make sure you look at each
CXXCtorInitializer for each CXXConstructorDecl you see.
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.
The main point of this change is to make sure that a shared function always has a body: both, in the optimizer pipeline and in the swiftmodule file.
This is important because the compiler always needs to emit code for a shared function. Shared functions cannot be referenced from outside the module.
In several corner cases we missed to maintain this invariant which resulted in unresolved-symbol linker errors.
As side-effect of this change we can drop the shared_external SIL linkage and the IsSerializable flag, which simplifies the serialization and linkage concept.
We used to only emit "destroy" and "initializeWithCopy". This commit adds support for emitting "assignWithCopy", "initializeWithTake" and "assignWithTake".
