FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
While private and protected fields coming from C++ cannot be accessed from Swift, they can affect Swift typechecking.
For instance, the Swift typechecker mechanism that adds implicit `Sendable` conformances works by iterating over all of the struct's fields and checking whether all of them are `Sendable`. This logic was broken for C++ types with private fields, since they were never accounted for. This resulted in erroneous implicit `Sendable` confromances being added.
Same applies for `BitwiseCopyable`.
In addition to this, ClangImporter used to mistakenly mark all C++ structs that have private fields as types with unreferenceable storage, which hampered optimizations.
As a side effect of this change, we now also provide a better diagnostic when someone tries to access a private C++ field from Swift.
rdar://134430857
This fixes an assertion failure:
```
Assertion failed: (isInstance() && "No 'this' for static methods!"), function getThisType, file DeclCXX.cpp, line 2636.
```
Clang changed it's handling of member call expressions in af4751738d causing the assertion to fail when synthesizing a forwarding function declaration for `static operator()`.
rdar://133257179
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)
This fixes a crash in SILGen when calling a C++ subscript that has an unnamed parameter from Swift.
The parameters from a C++ `operator[]` get carried over to the synthesized Swift subscript. If the Swift parameter has no name, there is no way to refer to it in SIL. However, the synthesized subscript accessor needs to pass this parameter to C++.
This change makes sure that we give a name to the Swift parameter if there isn't already a name on the C++ side.
rdar://83163841
This adds a new implementation of virtual method dispatch that handles reference types correctly.
Previously, for all C++ types an invocation of a virtual method would actually get dispatched statically. For value types this is expected and matches what C++ does because of slicing. For reference types, however, this is incorrect, we should do dynamic dispatch.
rdar://123852577
It should be the responsibility of callers to map the type to a
contextual type, as needed. When it's not possible or repetitive to do
so, there is a special-purpose function `isInterfaceTypeNoncopyable` for
Sema.
This allows calling a C++ function with default arguments from Swift without having to explicitly specify the values of all arguments.
rdar://103975014
The spelling kind was only ever set to
`StaticSpellingKind::None`, and the static location
was never used for anything (and should be queried
on the storage anyway). This doesn't affect the
computation of `isStatic` since `IsStaticRequest`
already takes the static-ness from the storage for
accessors.
For any operation that can throw an error, such as calls, property
accesses, and non-exhaustive do..catch statements, record the thrown
error type along with the conversion from that thrown error to the
error type expected in context, as appropriate. This will prevent
later stages from having to re-compute the conversion sequences.
Parse typed throw specifiers as `throws(X)` in every place where there
are effects specified, and record the resulting thrown error type in
the AST except the type system. This includes:
* `FunctionTypeRepr`, for the parsed representation of types
* `AbstractFunctionDecl`, for various function-like declarations
* `ClosureExpr`, for closures
* `ArrowExpr`, for parsing of types within expression context
This also introduces some serialization logic for the thrown error
type of function-like declarations, along with an API to extract the
thrown interface type from one of those declarations, although right
now it will either be `Error` or empty.
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
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
When importing a C header in the C++ language mode, Clang/Swift treat C structs as C++ structs.
Currently Swift synthesizes a default initializer that zero-initializes the backing memory of the struct for C structs, but not for C++ structs.
This is causing issues in existing projects that use C libraries and rely on having the default initializer available in Swift. This change enables the synthesis of a default initializer for C++ structs. Since many C++ structs are not designed to be initialized this way, the initializer is marked as deprecated in Swift.
rdar://109727620
I was hoping this would be enough to avoid the
crash in rdar://82820628, as we shouldn't emit
coverage mappings for synthesized Clang decls,
but it seems it can still cause Clang to crash
(rdar://100172217). Regardless, it seems like
these should be implicit anyway, so mark them as
such.
