This commit compares the decl inside the `@abi` attribute to the decl it’s attached to, diagnosing ABI-incompatible differences. It does not yet cover attributes, which are a large undertaking.
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
A protocol conformance can be ill-formed due to isolation mismatches
between witnesses and requirements, or with associated conformances.
Previously, such failures would be emitted as a number of separate
errors (downgraded to warnings in Swift 5), one for each witness and
potentially an extra for associated conformances. The rest was a
potential flood of diagnostics that was hard to sort through.
Collect all of the isolation-related problems for a given conformance
together and produce a single error (downgraded to a warning when
appropriate) that describes the overall issue. That error will have up
to three notes suggesting specific courses of action:
* Isolating the conformance (when the experimental feature is enabled)
* Marking the witnesses as 'nonisolated' where needed
*
The diagnostic also has notes to point out the witnesses/associated
conformances that have isolation problems. There is a new educational
note that also describes these options.
We give the same treatment to missing 'distributed' on witnesses to a
distributed protocol.
When diagnosing an isolation mismatch between a requirement and witness,
we would produce notes on the requirement itself suggesting the addition of
`async`. This is almost never what you want to do, and is often so far
away from the actual conforming type as to be useless. Remove this note,
and the non-function fallback that just points at the requirement, because
they are unhelpful.
This is staging for a rework of the way we deal with conformance-level
actor isolation problems.
Rework the type checker's diagnostics to support completely checking lifetime
dependence requirements. Don't let anything through without the feature being
enabled and complete annotation or inference.
The implementation of `withoutActuallyEscaping` for `@convention(block)`
functions cannot verify at runtime that the function did not actually
escape. Diagnose this as unsafe code under strict memory safety checking.
Fixes rdar://139994149.
This responds to some feedback on the forums. Most importantly this allows for
us to use variadic generics in the the type system to document whether we allow
for "appending" behavior or not. Previously, for some options we would take the
last behavior (and theoretically) for others would have silently had appending
behavior. This just makes the behavior simple and more explicit.
With the move to explicitly specifying the global actor for an isolated
conformance, we can now have conformances whose isolation differs from
that of the type, including having actors with global-actor-isolated
conformances. Introduce this generalization to match the proposal, and
update/add tests accordingly.
We introduce a new macro called #SwiftSettings that can be used in conjunction
with a new stdlib type called SwiftSetting to control the default isolation at
the file level. It overrides the current default isolation whether it is the
current nonisolated state or main actor (when -enable-experimental-feature
UnspecifiedMeansMainActorIsolated is set).
When deserialization a protocol conformance from a binary swiftmodule
file the compiler can encounter inconsistencies caused by stale module
files. Replace the hard crash with a proper error and print the list of
requirements and conformances being compared to stderr for manual
inspection. Recover silently when we can afford to, during indexing or
in LLDB.
Failures in `readNormalProtocolConformanceXRef` are usually caused by a
dependency change without the required rebuild of its dependents.
Display a proper error instead of crashing when encountering such an
issue during normal compilation. Recover silently when we can afford to,
during indexing or in LLDB.
`AvailabilityRange` is now being used as a currency type in more of the
compiler, and some of those uses are in permanent `ASTContext` allocations. The
class wraps the `VersionRange` utility, which is itself a wrapper around
`llvm::VersionTuple` with some additional storage for representing sentinel
values. Even though the two sentinel values can be be represented with just a
single bit of additional storage on top of the 16 bytes required to represent
`VersionTuple`, because of alignment requirements the sentinel values end up
bloating the layout of `VersionRange` by many bytes.
To make `AvailabilityRange` and `VersionRange` more efficient to store, we can
instead reserve two unlikely `llvm::VersionTuple` bit patterns as the sentinel
values instead. The values chosen are the same ones LLVM uses to represent
version tuple tombstones and empty keys in a `DenseMap`.
This is the missing check for "rule #1" in the isolated conformances proposal,
which states that an isolated conformance can only be referenced within
the same isolation domain as the conformance. For example, a
main-actor-isolated conformance can only be used within main-actor code.
Within the constraint system, introduce a new kind of conformance constraint,
a "nonisolated conforms-to" constraint, which can only be satisfied by
nonisolated conformances. Introduce this constraint instead of the normal
conforms-to constraint whenever the subject type is a type parameter that
has either a `Sendable` or `SendableMetatype` constraint, i.e., when the type
or its values can escape the current isolation domain.
