It should no longer be necessary to provide an `@_alwaysEmitIntoClient` version
of `_diagnoseUnavailableCodeReached()`. This workaround was originally added to
provide compatibility with projects that were misconfigured to compile against
a newer stdlib but link against an older one.
Resolves rdar://119892482.
When deriving `Hashable` and `Equatable` for enums, use
`Decl::isUnreachableAtRuntime()` to determine whether or not to insert
`_diagnoseUnavailableCodeReached()` traps for specific enum elements. This
fixes a bug where inappropriate traps were inserted for enum elements that are
unavailable for app extensions. It also fixes a bug where traps were inserted
when building a zippered library for macOS and enum elements were unavailable
on macOS but not for macCatalyst clients.
Resolves rdar://125371621
The `_diagnoseUnavailableCodeReached()` function was introduced in the Swift
5.9 standard library and employs `@backDeployed` to support compilation of
binaries that target OS releases aligned with earlier Swift releases.
Unfortunately, though, this backdeployment strategy doesn't work well for some
unusual build environments. Specifically, in some configurations code may be
built with a compiler from a recent Swift toolchain and then linked against the
dylibs in an older toolchain. When linking against the older dylibs, the
`_diagnoseUnavailableCodeReached()` function does not exist but the
`@backDeployed` thunks emitted into the binary reference that function and
therefore linking fails.
The idea of building with one toolchain and then linking to the dylibs in a
different, older toolchain is extremely dubious. However, it exists and for now
we need to support it. This PR introduces an alternative
`_diagnoseUnavailableCodeReached()` function that is annotated with
`@_alwaysEmitIntoClient`. Calls to the AEIC variant are now emitted by the
compiler when the deployment target is before Swift 5.9.
Once these unusual build environments upgrade and start linking against a Swift
5.9 toolchain or later we can revert all of this.
Resolves rdar://119046537
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.
Since it's now possible to refer to static members declared on a protocol
metatype if result type conforms to the protocol we need to adjust failure
detection to identify that conformance failure means and invalid reference
in certain situations.
If base type of a unresolved member reference couldn't be determined
(represented as a hole type), before recording a fix about lack of
contextual information, let's make sure that hole originated in either
base or result type of this reference, otherwise the problem is
contextual e.g. generic parameter, which supposed to act as contextual
type for a reference, couldn't be inferred.
`SK_Fix` was used to indicate that solver has encountered a hole
along the current path but since there is `SK_Hole` now, increasing
`SK_Fix` no longer makes sense.
It might be either impossible to infer the base because there is
no contextual information e.g. `_ = .foo` or there is something
else wrong in the expression which disconnects member reference
from its context.
This warning is produced if you annotate an enum with `@frozen` but
build without library evolution enabled. The problem is that if you
only build with library evolution enabled for release builds, this
leaves you with a warning for all debug builds. The downside of this
change is that if you never build with library evolution, you may have
this unnecessary annotation without noticing.
all cases of missing generic parameters.
In `ComponentStep::take` when there are no bindings or disjunctions, use hole
propagation to default remaining free type variables that aren't for generic
parameters and continue solving. Rather than using a defaultable constraint for
holes, assign a fixed type directly when we have no bindings to try.
In order to remove the enum raw value check request in validateDecl,
IRGen must now tolerate recieving an invalid raw value expression.
Switch the assert to instead check for this condition and emit an
invalid negative discriminator.
Argument-to-Parameter mismatch handles conformance failures
related to arguments, so the logic in `MissingConformanceFailure`
which wasn't entirely correct is now completely obsolete.
Resolves: rdar://problem/56234611
In preparation for checkEnumRawValues being turned into a request, move the common diagnostics to the decl checker so they're always emitted at the right time.
@objc enums have special requirements on the raw type, which were
enforced as part of checking the raw type of the enum. Rework the
checking here so that the additional constraints are part of resolving
whether the enum is exposed to Objective-C. This keeps raw-type
computation more independent and “lower-level” than @objc computation.
Once reworked, eliminate the “CIntegerTypes” cache from TypeChecker:
it probably doesn't matter, and the caching should be performed by the
request-evaluator rather than the type checker.
In Swift 4, constructors had the same name as properties,
methods and enum cases named `init`. This meant that you
could use constructor syntax to call such a member, which
caused some confusing behavior.
Recently I added a special declname for `init` so that
constructors have unique names distinct from any name you
can spell, and "foo.init" syntax would look for a member
with the special name rather than one named `init`.
Unfortunately people actually had code where they defined
members named `init` and then use them via normal member
lookup syntax, like this:
enum E {
case `init`
}
let e: E = E.init
So to maintain backward compatibility, hack member lookup
to also find members named `init` when looking up the special
declname for constructors.
The workaround is only enabled in Swift 4 and 4.2 mode;
in Swift 5 mode you are expected to write "foo.`init`" to access
non-constructor members named `init`.
Fixes <rdar://problem/38682258>.
This fixes a 4.2 regression where enums and subscripts could not
contain single-argument function types with an 'inout' parameter,
because we erroneously diagnosed the 'inout' as if it appeared
at the top level of the enum case or subscript index type.
Fixes <https://bugs.swift.org/browse/SR-7890>.
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
