The body of a function has to be re-analyzed for every call
site of the function, which is very expensive and if the
body is not changed would produce the same result.
This takes about ~10% from swift-syntax overall build time
in release configuration.
An "abstract" ProtocolConformanceRef is a conformance of a type
parameter or archetype to a given protocol. Previously, we would only
store the protocol requirement itself---but not track the actual
conforming type, requiring clients of ProtocolConformanceRef to keep
track of this information separately.
Record the conforming type as part of an abstract ProtocolConformanceRef,
so that clients will be able to recover it later. This is handled by a uniqued
AbstractConformance structure, so that ProtocolConformanceRef itself stays one
pointer.
There remain a small number of places where we create an abstract
ProtocolConformanceRef with a null type. We'll want to chip away at
those and establish some stronger invariants on the abstract conformance
in the future.
With this approach, you cannot tell whether a parameter is addressable only
from the function type. Instead you need the SILValue that will be passed to the
call site.
Preserve conditionallyAddressableParamIndices independent of any
addressableParamIndices. The conditional dependencies are subject to change
based on type substitution.
* [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.
This will be used by lldb. I'd like to add it to swift-inspect too, but that will require figuring out how to evolve the swift runtime's ABI.
rdar://147448235
Previously, we handled cases where we had an actual SILDeclRef constant (e.x.:
an actual function ref), but we did not handle cases where we did not have a
constant but instead just had a FunctionTypeIsolation. We now handle that
correctly.
Introduce the experimental feature InferIsolatedConformances to align
with the upcoming feature proposed in SE-0470. This is a slight
generalization of the main-actor-specific inference that was already
in place for the default-main-actor mode from SE-0466. Note that, as
specified in SE-0470, InferIsolatedConformances is implied by the
default-main-actor mode.
When importing C++ decls in symbolic mode, class templates are not instantiated, which means they might not have a destructor or a move constructor. Make sure we are not trying to diagnose those missing lifetime operations in symbolic mode.
This fixes incorrect diagnostics that were emitted during indexing at the end of compilation:
```
warning: 'import_owned' Swift attribute ignored on type 'basic_string': type is not copyable or destructible
```
As a nice side effect, this moves the logic that emits these diagnostics from the request body, which might be invoked many times, to the importer itself, which is only invoked once per C++ class.
rdar://147421710
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.
https://github.com/swiftlang/swift/pull/79807 caused a regression in which
`AvailabilityContext` stopped tracking the available version range for the
active platform domain for certain platforms. Fix this by reverting to checking
`AvailabilityDomain::isActive()` to determine when a given platform
`AvailabilityDomain` represents the target platform. The compiler's existing
mapping from target triple to platform domain is incomplete and it's not clear
to me whether fixing that could cause other regressions.
Resolves rdar://147413616.
`-Xfrontend -enable-cond-fail-message-annotation`
LLVM IR produced by the Swift compiler will add the `annotation`
metadata attribute to the branch instruction generated for cond_fail
builtins.
Rather than emitting isolation-related diagnostics for conformances, such
as witnesses that have incompatible isolation or associated conformances
that are differently isolated, capture all of those diagnostics in a
single side table and diagnose them all together.
This refactoring doesn't change the way we actually diagnose the
issue. That comes next.
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 to support completely checking lifetime dependence
requirements. Don't let anything through without the feature being enabled and
complete annotation or inference.
First, prevent lifetime dependencies from sneaking into source that does not
enable LifetimeDependence. This is essential for controlling the scope of the
feature.
Fixing this is disruptive because, ever since `~Escapable` was introduced we
have been declaring empty non-Escapable types without enabling
LifetimeDependence. Such as:
struct Implicit_Init_Nonescapable : ~Escapable {}
Fixes: rdar://145979187 ([nonescapable] diagnose implicit non-Escapable
initializers as an error unless LifetimeDependence is enabled)
Various forms of unsupported 'inout' dependencies are now also caught by the
type checker.
Second, disable lifetime dependency inferrence except in unambiguous cases and
some implicitly generated cases.
Fixes: rdar://131176898 ([nonescapable] missing diagnostic for incorrectly inferred inherited dependence)
This is important to avoid source compatibility problems as inference rules
change. They will change as the proposal goes through review.
This fixes various latent missing dependency bugs.
Disable experimental lifetime dependence inference. Unambiguous lifetime
dependency candidates will still be inferred by default, without any frontend
options. Ambiguous candidates will, however, no longer be inferred unless
-Xfrontend -enable_experimental_lifetime_dependence_inference is enabled.
This all has to be done without breaking existing .swiftinterface files. So
backward compatibility logic is maintained.
Examples of inference rules that are no longer enabled by default:
1. do not infer a dependency on non-Escapable 'self' for methods with more than
zero parameters:
extension NE: ~Escapable {
/*@lifetime(self)*/ // ERROR: 'self' not inferred
func method<Arg>(arg: Arg) -> NE { ... }
}
2. Never infer a 'copy' dependency kind for explicit functions
extension NE: ~Escapable {
@lifetime(self) // ERROR: 'copy' not inferred
func method() -> NE { ... }
@lifetime(self) // ERROR: 'copy' not inferred
var property : NE { /*@lifetime(self: newValue)*/ set { ... } }
}
