This reverts commit 6852bc9834.
In addition to the original change, this makes sure that C++ `std::string` and Swift `String` are given distinct score, in order to prevent ambiguity which was causing build failures in some projects.
rdar://158439395
Exclude properties with initial values from the memberwise initializer
if they are less accessible than the most accessible property, up to
`internal`. Introduce a compatibility overload that continues to
include the same properties as before until the next language mode.
This is gated behind the `ExcludePrivateFromMemberwiseInit` feature.
rdar://122416579
This serves as the backing request for both InitAccessorPropertiesRequest
and MemberwiseInitPropertiesRequest, ensuring the former does not
care about the init accessor is included in the memberwise initializer.
Store the original VarDecl in the same map we use for tracking the
original wrapper var for property wrappers. This will allow us to
use the same logic to determine the original var for both.
Add a note to missing explicit `Sendable` conformance warning
(produced by `-Wwarning ExplicitSendable`) and a fix-it with
a suggestion to suppress `Senable` conformance via `~Sendable`.
This attribute introduces some conversions between the annotated smart
pointer type and the native swift reference type. In the future we plan
to introduce bridging so the smart pointer type can be hidden in the
signature and we can automatically convert it to the native Swift
reference type on the ABI boundaries.
This PR is using a new way to use swift_attr attributes. Instead of
doing the parsing in the clang importer it falls back to Swift's
attribute parsing and makes sure that the annotation has valid Swift
attribute syntax.
rdar://156521316
This introduces support for converting a Swift closure that captures variables from its surrounding context into an instance of `std::function`, which is useful for working with C++ APIs that use callbacks.
Each instantiation of `std::function` gets a synthesized Swift constructor that takes a Swift closure. Unlike the previous implementation, the closure is _not_ marked as `@convention(c)`. The body of the constructor is created lazily.
Under the hood, the closure is bitcast to a pair of a function pointer and a context pointer, which are then wrapped in a C++ object, `__SwiftFunctionWrapper`, that manages the lifetime of the context object via calls to `swift_retain`/`swift_release` from the copy constructor and the destructor. The `__SwiftFunctionWrapper` class is templated, and is instantiated by ClangImporter.
rdar://133777029
In #85757, part of the changes resolving #68944 is submitted. Most
bridges required for #85757 were previously implemented in #84648. After
#82653 got merged, we have demand for several new bridges in order to
properly support optimizing derivatives of throwing functions via
AutoDiff Closure Specialization pass.
This patch implements:
- **AST:**
* `var optionalObjectType: Type` property of `Type` struct
* `var optionalType: Type` property of `Type` struct
- **SIL:**
* `let name: StringRef` property of `EnumCase` struct
* `func createOptionalSome(operand: Value, type: Type) -> EnumInst`
method of `Builder`
* `func createOptionalNone(type: Type) -> EnumInst` method of `Builder`
We need special handling for protocols whose requirement
signature exists but is in a serialized state, as we
cannot run the StructuralRequirementsRequest on such
a protocol as there's no work to be done, effectively.
This is similar to SuppressedAssociatedTypes, but infers
default requirements when primary associated types of
protocols are suppressed. This defaulting for the primary
associated types happens in extensions of the protocol,
along with generic parameters, whenever a source-written
requirement states a conformance requirement for the protocol.
Thus, the current scheme for this defaulting is a simplistic,
driven by source-written requirements, rather than facts
that are inferred while building generic signatures.
Defaults are not expanded for infinitely many associated types.
rdar://135168163
When a custom domain is described on the command line, there is no
backing declaration for it. Serialize such custom domains by
identifier and look them up globally at the point of deserialization.
When that fails, warn and drop the annotation.
This is all a stopgap until we have a way to spell custom availability
domains in the Swift language itself.
Although this error can only happen when tinkering with the stdlib's runtime functions, it's nice to get a readable error message. So far, the compiler just crashed later without a hint to the original problem.
