Consider this code:
protocol P {
associatedtype A
...
}
protocol Q: P {
associatedtype A = Int
...
}
struct S: Q {
...
}
If we check the [S: Q] conformance first, we get the right type witness
assignment, but if we check [S: P] first, conformance checking fails.
Instead of looking at an associated type declaration and any associated
types that it overrides, we now look through all associated types with the
same name among the protocols the adoptee conforms to. This allows us to
find the default assignment 'A = Int' from Q regardless of request
evaluation order.
Fixes rdar://problem/119052782.
In cases where a subclass was unable to synthesize any initializers
(for example, because there were missing designated initializers in the
superclass), we were skipping checking of superclass required
initializers. This meant that we would silently accept subclasses that
cannot be initialized directly (that would produce an error), but
could at runtime be initialized via a required initializer... that
didn't account for the subclass.
Fixes the original problem from https://github.com/apple/swift/issues/69965,
but not the most minimal one.
We accepted unnamed closure parameters if the type was an array literal, dictionary literal, tuple or function (because the `[` or `(` starting the type was sufficient to disambiguate the type from the parameter’s name). This was never an accepted syntax and we should disallow it.
The "typechecked function body" request was defined to type-check a
function body that is known to be present, and not skipped, and would
assert these conditions, requiring its users to check whether a body
was expected. Often, this means that callers would use `getBody()`
instead, which retrieves the underlying value in whatever form it
happens to be, and assume it has been mutated appropriately.
Make the "typechecked function body" request, triggered by
`getTypecheckedBody()`, more resilient and central. A `NULL` result is
now acceptable, signifying that there is no body. Clients will need to
tolerate NULL results.
* When there is no body but should be one, produce an appropriate
error.
* When there shouldn't be a body but is, produce an appropriate error
* Handle skipping of function bodies here, rather than elsewhere.
Over time, we should move clients off of `getBody` and `hasBody`
entirely, and toward `getTypecheckedBody` or some yet-to-be-introduced
forms like `getBodyAsWritten` for the pre-typechecked body.
Rethrows checking is based on the interface type of the parameter, with
substitutions applied only when we need to figure out the thrown error
type. Fixes a regression caused by my attempt at dealing with parameter
packs in rethrows functions.
Effects checking for rethrowing functions was using unsubstituted
interface types for the parameter list. When a rethrows function has
parameter pack arguments, the interface type may have a different
number of parameters from the resulting argument list, causing the
effects checking to bail out early.
This has been wrong since the introduction of parameter packs, but
recent refactoring of effects checking ended up promoting this bug to
a compiler crash. Fix the bug, and make sure we don't crash if the
effects checker hits an issue here.
Fixes rdar://116740385.
When substitution into a function type with `throws(E)` produces either
`throws(any Error)` or `throws(Never)`, adjust the resulting function
type to the equivalent `throws` or non-throwing.
When substitution into a function type with `throws(E)` produces either
`throws(any Error)` or `throws(Never)`, adjust the resulting function
type to the equivalent `throws` or non-throwing.
Allow a rethrows function to call a typed-throws function that has a
specific form that looks like it only rethrows, i.e., it is generic
over its thrown error type and carries the thrown error type from its
closure parameters to itself. This is a compatibility carve-out to
allow existing rethrows functions to move to typed throws without
breaking their clients.
Note that it is possible to write a sneaky function that passes this
check but throws when it shouldn't, so this compatibility carve-out is
phased out with the upcoming feature FullTypedThrows.
Rethrows functions only throw when their closure arguments throw.
However, they are free to translate the errors thrown from the closure
arguments in any way they want, and are therefore untyped.
Ensure that calls to `rethrows` functions are always treated as
throwing `any Error` if their closure arguments throw anything.
* implementing changes and tests
* added unit test using throws
* adding test with distributed actor
* moved distributed-actor tests to another file
* revert import Distributed
When providing a key-path literal for a parameter of function type
where that function type has a generic parameter for its thrown error
type, infer `Never` for the generic argument because key paths don't
throw.
Thanks to @xedin for realizing that this would be an issue.
Extensions to lightweight generic classes are such a huge mess that we’re just removing these from the feature’s scope for now.
Fixes rdar://116066409.
Allow one to throw a type that is convertible to `any Error` even if it
doesn't conform to the `Error` protocol, e.g., an existential type like
`any Codable & Error`.
Required and designated inits have to be overridable—the former so that uses of the initializer on `any T.Type` will call the subclass initializer, the latter so that inherited convenience inits will call the subclass initializer. However, Swift-only members use vtables to dispatch to subclasses, and @objcImpl classes don’t have vtables, so their Swift-only inits cannot be made overridable. Upshot: Swift-only inits on @objcImpl classes must be `convenience`, not `required` or designated.
Enforce this rule in the ObjCImplementationChecker.
Fixes rdar://109121293.
Nothing in an `@_objcImplementation` block—including Swift-only declarations—should ever require a vtable entry. Diagnose any such members.
The diagnostic emitted here is intended to be a fallback that will be used when a vtable entry is needed but we don’t know the specific reason. A future commit will add a more specific diagnostic for Swift-only non-convenience inits.
Besides improving diagnostics, this also allows us to track whether there were any @objc failures using the invalid bit on the @_objcImplementation attribute.
Initializers can’t be made final, but they *can* be made @nonobjc. (This isn’t always enough to ensure they’re actually valid, but I’ll get to that in a follow-up commit.)
The fix-it suggesting that an unmatched `@objc`-able member can be turned `private` always suggested adding a new modifier, even if one already existed. Make it suggest replacing the existing one instead.
Suppose a superclass declares an initializer unavailable and then a subclass wants to redeclare and use it. Formally, the subclass declaration overrides the superclass one; however, Swift will not actually require the subclass to use the `override` keyword. As currently implemented, this means that the requirement will be skipped as an override, but the candidate will be included as a member implementation. Result: a “candidate does not match any requirement” diagnostic.
Fix this by skipping requirements that are overrides *only* if the declaration they override is not unavailable.
Fixes rdar://109541045.
The type that occurs as the thrown error type must conform to the
`Error` protocol. Infer this conformance when the type is a type
parameter in the signature of a function.
When comparing a requirement that uses typed throws and uses an
associated type for the thrown error type against a potential witness,
infer the associated type from the thrown error of the
witness---whether explicitly specified, untyped throws (`any Error`),
or non-throwing (`Never`).
Lift the subtyping check for thrown error types out of the constraint
solver, so we can re-use it elsewhere.
There is a minor diagnostic change, from one that is actively
misleading (it shows a legitimate conversion that's wrong) to one that
is correct, which comes from us not treating "dropping throws" as a
legitimate way to handle equality of function types.
