Default initializable init properties shouldn't prevent default
init synthesis and such properties without anything to initialize
should be considered by it.
Fixes a bug were default initializer for an init accessor property
hasn't been synthesized even when the property is marked as default
initializable.
Resolves: rdar://113421273
Temporarily cherry-pick Swift 5.9’s behavior of turning @objcImplementation errors into warnings to 5.10 until we fix the last few bugs in these diagnostics.
Because `required init`s do not have the `override` keyword, they are always treated as member implementations (if they pass other checks). However, these methods sometimes actually are overrides, and when they are, they should not be treated as member implementations. This results in required inits being treated as candidates when there won’t be a requirement for them to match.
Hack around this by separately checking for this situation and skipping the affected members.
Fixes rdar://112910098.
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
The cached values for `hasOnlyCasesWithoutAssociatedValues()` and
`hasPotentiallyUnavailableCaseValue()` are computed in a single pass over the
elements of an `EnumDecl`. However, the pass would return early after finding
an element with an associated value, without checking whether any of the rest
of the elements were potentially unavailable. This made `Comparable` synthesis
succeed for any enum with potentially unavailable elements so long as the first
element in the enum has an associated value.
The original bug was a crash-on-invalid with a missing '}', but it
actually exposed a bug with nested protocols (SE-0404) and another
long-time bug.
- Whatever we do, we should skip this for protocols because their 'Self'
parameter is not bound from context.
- getTrailingWhereClause() is not the right proxy for "has a generic
signature different than its parent", in particular it doesn't
round-trip through serialization. Instead, just compare generic
signatures for pointer equality in the early return check.
The second change is source-breaking because it was possible to
write a nested type with a `where` clause and use it contradicting
its requirements across a module boundary.
Fixes rdar://113103854.
When deriving the `hash(into:)` and `==` witnesses for `Hashable`/`Equatable`
enums, call `_diagnoseUnavailableCodeReached()` in the case bodies for
unavailable enum elements. This is needed because the previously derived code
would operate on the values associated with unavailable enum elements, which is
illegal if the types of those associated values are also unavailable (these
case bodies would have failed typechecking had they been hand-written). The new
structure also more explicitly documents that reaching these cases is
unexpected, since unavailable enum elements should not be instantiated at run
time.
The compiler derived implementations of `Codable` conformances for enums did
not take enum element unavailability into account. This could result in
unavailable values being instantiated at runtime, leading to a general
violation of the invariant that unavailable code is unreachable at runtime.
This problem is possible because synthesized code is not type checked; had the
conformances been hand-written, they would have been rejected for referencing
unavailable declarations inside of available declarations.
This change specifically alters derivation for the following declarations:
- `Decodable.init(from:)`
- `Encodable.encode(to:)`
- `CodingKey.init(stringValue:)`
Resolves rdar://110098469
The restriction that default arguments be disallowed from accessing
`@usableFromInline` decls is overbearing for library developers who need to
write non-trivial code to compute a default value, since it forces them to
either write a verbose closure inline in the function signature or expose a
`public` helper function which unnecessarily expands API surface. A
`@usableFromInline` function a more reasonable way to encapsulate a verbose
default value computation.
This reverses the semantic changes included in https://github.com/apple/swift/pull/15666.
Resolves rdar://112093794.
Per the clarification during the review thread, all properties with
init accessors (including those that do not initialize any underlying
storage) are part of the memberwise initializer.
ClangImporter can import some methods as throwing that `@objc` cannot generate. For instance, an imported Objective-C method with an error out parameter in an unconventional position can still be imported as throwing no matter its selector, but `@objc` can only generate an error out parameter in an unconventional position if the matching selector part consists of the word `error` or (for the first part) ends with `Error`. Detect and diagnose these situations.
Note that the tests do not cover all of the new diagnostics because some of these conditions (like the `Void` parameter) cause selector mismatches and others (like the owned error parameter) are representable in the compiler but cannot currently be imported. I have chosen to add these diagnostics anyway in case there is a corner case that I haven’t discovered.
Fixes rdar://110100071.
The @objcImpl checker would accidentally dereference a null pointer when it tried to check if an async requirement could be satisfied by a non-async method. Fix that mistake.
Fixes rdar://111064481.
Add a special case for `TypeExpr` due to i.e. context specialization,
in such cases there is nothing for the solver to "open" so we need
to form opened type map manually.
Resolves: rdar://111059036
Initialization expressions are not allowed on computed properties
but if a property has `init` accessor it should be allowed because
it could be used by a memberwise initializer.
Allow keywords after `#` in freestanding macro expansions
There is no reason why we shouldn’t allow keywords here.
I also thought about allowing keywords after `@` but things become tricky here for two reasons:
- In the parser, we parse a type after the `@`, which could start with a keyword itself (e.g. `any`). If we want to keep the parser logic to parse a type after `@` (which I think we should), then it becomes unclear what `@any T` should parse as.
- We allow a space between `@` and the type name. This makes it very hard for recovery to tell whether `@ struct` refers to an attribute with name `struct` or if the user forgot to write the attribute name after `@`.
Since almost all keywords are lowercase and attached member macros are usually spelled with an uppercase name, there are a lot fewer chances for clashes here, so I don’t think it’s worth allowing keywords after `@`.
https://github.com/apple/swift/issues/66444
rdar://110472060
@objcImpl extensions aren’t allowed to declare new conformances; instead, they should either be declared in the header or in an ordinary extensions. (If they were permitted, they’d be ignored.)
Fixes rdar://110669366.
Skip stored properties that are initialized via init accessors and
emit parameters/initializations in field order which allows us to
cover more use-cases.
If some property is initializable by one than one init accessor
let's not sythesize a memberwise initializer in that case because
it's ambiguous what is the best init accessor to use.
