Forward the owning cleanup for the temporary buffer (if needed) instead of
creating a new cleanup, to avoid a double-free when both the initialization
cleanup and the value cleanup execute. Fixes rdar://147961840.
When a generic function has potentially Escapable outputs, those outputs
declare lifetime dependencies, which have no effect when substitution
leads to those types becoming `Escapable` in a concrete context.
This means that type substitution should canonically eliminate lifetime
dependencies targeting Escapable parameters or returns, and that
type checking should allow a function value with potentially-Escapable
lifetime dependencies to bind to a function type without those dependencies
when the target of the dependencies is Escapable.
Fixes rdar://147533059.
This removes the IsolatedConformances feature gate from SILGen for
dynamic casts, such that all dynamic casts that will not work with
isolated conformances are marked as such. Isolated conformances can
still only come into a program when part of it enables the feature
flag.
The last step in building a generic signature is to sort the requirements.
Requirements are sorted by comparing their subject types. If two
requirements have the same subject type, which can only happen with
conformance requirements, we break the tie by comparing protocol
declarations.
We compare protocol declarations using TypeDecl::compare(), which is a
shortlex order on the components of the fully qualified name of a
protocol (eg, Swift.Sequence, etc.)
While this order is part of the ABI, it has not been updated over the
years for several important changes:
- It did not handle module aliases; if we import a module via an
alias, we should use the real module name to compare protocols, and
not the aliased name. This produced inconsistent results if the
same module was imported under different names, which can happen
with module interface files that use module aliases.
- It did not handle the -module-abi-name flag. Changing the ABI name
of a module changes how we mangle protocol names, and the order
should match the mangling.
This change fixes the first case only. The second requires more
careful staging, because of _Concurrency and CompilerSwiftSyntax.
Fixes rdar://147441890.
Postfix operators can further be chained within an optional binding
chain, so we need to make sure they're handled in
`getMemberChainSubExpr`. Unresolved member chains still don't allow
them, so we need to add a new `kind` parameter to differentiate the
behavior here.
rdar://147826988
PR #79084 adjusted the projection logic for addressor accessors to avoid
a temporary materialization in cases where the base value is already in
memory; however, many LValue physical components were still unconditionally
using `ManagedValue::forLValue` and causing unnecessary materializations
from already-read-accessed memory locations. Fixes rdar://147705667.
Factor out `ConstraintSystem::getExplicitCaughtErrorType` from
`getCaughtErrorType`. Then use this for the contextual
type for a `throw` syntactic element.
rdar://139000351
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.
As part of the criteria to determine whether a method override requires a new
vtable entry in addition to overriding the base class's vtable entry for the
method, we compare the visibility of the base class to that of the derived
class, since if further subclasses of the derived class cannot see the original
base class's method descriptor, they would not be able to directly override its
vtable entry.
However, there was a subtle inconsistency in our checks in two different
places: `NeedsNewVTableEntryRequest::evaluate` compared the visibility of the
derived method to its immediate override method, whereas
`SILGenModule::emitVTableMethod` compared visibility with the ultimate base
method that originated the vtable entry in question. Internal imports create
a situation where this leads to inconsistent answers, causing us to emit
a vtable thunk but without a corresponding new vtable entry, causing the thunk
to become self-recursive (rdar://147360093). If the base class is in a separate
module:
```
// Module1
open class Base {
public required init() {}
}
```
and an intermediate class inherits that base class, it must `public import`
the module in the file defining the class to do so:
```
// Module2
public import Module1
open class MidDerived: Base { }
```
However, another file in the same module can further inherit that class, but
with only an `internal import` of the base module:
```
// Also Module2
import Module1
open class MostDerived: MidDerived { }
```
The implicit `init()` is `public` in each class, but from the perspective of
`MostDerived.init`, `Base.init` is `internal` because of the import. However,
the fact that its immediate parent is `public` should be sufficient evidence
that its original definition had visibility to `Base`, so no thunk should
be necessary.
Regardless of the value specified for `-unavailable-decl-optimization`, decls
that are unavailable in custom availability domains should be treated as always
unreachable at runtime.
Part of rdar://138441307.
We iterate over the DenseMap and simplify both types appearing
in the key. If multiple keys simplify to the same type, later
keys overwrite earlier keys, so the outcome depends on hash
table order.
Fix this by introducing an arbitrary tie break: we prefer the
highest-numbered restriction.
Fixes rdar://146780049.
Generalize the implementation of `SemanticDeclAvailabilityRequest` in
preparation for adding a new case to `SemanticDeclAvailability`. Use the
centralized availability constraint query instead of implementing a bespoke
algorithm for gathering constraints. Simplify `SemanticDeclAvailability` by
removing a case that is no longer relevant.
Part of rdar://138441307.
Extract the tests that verify back deployment of the standard library function
`diagnoseUnavailableCodeReached()` into a separate, multi-platform test.
Parameters of generic type need to be treated as potentially
addressable-for-dependencies, but we don't want callers using the generic
function with concrete types that are known not to be addressable-for-
dependencies to be overconstrained. In SILFunctionType lowering, lower
these dependencies distinctly as conditionally addressable, meaning that
the dependency on an argument depends on whether the concrete type of
that argument is (potentially) addressable-for-dependencies or not.
To ensure that dependent values have a persistent-enough memory representation
to point into, when an immutable binding is referenced as an addressable
argument to a call, have SILGen retroactively emit a stack allocation and
materialization that covers the binding's scope.
To ensure that dependent values have a persistent-enough memory representation
to point into, when an immutable binding is referenced as an addressable
argument to a call, have SILGen retroactively emit a stack allocation and
materialization that covers the binding's scope.
