The new logic no longer includes non-generic parent types as part
of the type reference.
This also combines the 32- and 64-bit tests validations, since they
were identical for this test anyway.
This is a more correct fix for the issue that inspired PR #62854.
In particular, this does not change the numbering of generic
argument levels, and so does not break generic type parameter
lookups.
Added a new test case to verify that nested types that mix
generics and non-generics in different ways consistently identify
the correct generic argument labels.
Allowed SILFunctionType instances for pseudogeneric coroutines without
signatures to be created. Such instances are created by
SILTypeSubstituter::substSILFunctionType when SILGen'ing a conformance
of a pseudogeneric type to a protocol featuring a coroutine requirement.
rdar://81421394
Because `_taskLocalValuePush` and `_taskLocalValuePop` can result in calls
to `swift_task_alloc` and `swift_task_dealloc` respectively, and because
the compiler hasn't been taught about that (e.g.
`SILInstruction::isAllocatingStack`,
`SILInstruction::isDeallocatingStack`, etc), calling them (push and pop)
from a function which makes use the stack for dynamically sized
allocations can result in violations of stack discipline of the form
```
swift_task_alloc // allocates %ptr_1
copy_value_witness // copies into %ptr_1
swift_task_localValuePush // calls swift_task_alloc and allocates %ptr_2
swift_task_dealloc // deallocates %ptr_1
swift_task_localValuePop // calls swift_task_dealloc and deallocates %ptr_2
```
Avoid the problem by not allocating dynamically sized stack space in the
function which calls `_taskLocalValuePush` and `_taskLocalValuePop`.
Split the calls to those functions into `withValueImpl` function which
takes its argument `__owned`. Call that function from `withValue`,
ensuring that the necessary copy (to account for the fact that withValue
takes its argument `__guaranteed` but `_taskLocalValuePush` takes its
`__owned`) and associated stack traffic occur in `withValue`.
Still, allow `withValueImpl` to be inlined. The stack nesting will be
preserved across it.
rdar://107275872
In particular, the exactly internal layout of Array<> is quite
different between macOS and Linux, which makes it impractical
for use in tests like this. An empty class is still a reference
and doesn't introduce so many complications.
Follow-up to https://github.com/apple/swift/pull/65048
`getDesugaredType` unwraps sugar types that appear in sequence,
to remove sugar from nested positions we need to get a canonical type.
Thanks to @slavapestov for pointing it out.
Generic type aliases, unless desugared, could bring unrelated type variables
into the scope i.e. `TypeAlias<$T, $U>.Context` is actually `_Context<$U>`.
These variables could be inferrable only after the the body the closure is
solved. To avoid that, let's adjust `TypeVariableRefFinder` to desugar types
before collecting referenced type variables.
Resolves: rdar://107835060
* [IRGen] Pass component generic sig when emitting key path component for external property
rdar://101179225
When no generic environment was present, we passed nullptr, which is not correct when the property uses an external associated type, causing crashes in IRGen. In those cases, we have to pass the component generic sig instead.
* Fix test
A "generic" case is any case whose payload type depends
on generic type parameters for the enum or any enclosing type.
Some examples:
```
struct S<T> {
enum E {
case a // Non-generic case
case b(Int) // Non-generic case
case c(T) // Generic case
case d([U]) // Generic case
case e([Int]) // Non-generic case
}
}
```
This is important for correctly distinguishing MPE versus
SPE layouts. A case is considered "empty" only if it
is either a non-payload case (`case a`) or if the payload
is zero-sized and non-generic. Generic cases are always
treated as non-zero-sized for purposes of determining
the layout strategy.
Correctly testing this is tricky, since some of the
layout strategies differ only in whether they export
extra tag values as XIs. The easiest way to verify is
to check whether wrapping the result in an `Optional<>`
adds another byte to the overall size.
This exercises a number of cases that the previous logic got
wrong, including cases where MPEs are laid out like SPEs,
and cases where we use the SPE or MPE layout strategies for enums
that have no non-empty payloads. (These cases are superficially
similar but differ in how they handle XIs.)
These new tests allowed me to correct a number logical flaws
about how layouts are selected. In particular, cases with
generic payloads are always considered to be non-empty for
purposes of selecting a layout strategy. Only cases that
are statically known to be empty are considered empty for
layout purposes.
When computing linkage, the compiler would treat unavailable declarations as if
they were "always available" when they lack an `introduced:` version:
```
// Library
@available(macOS, unavailable)
public func foo() {
// …
}
// Client
import Library
@available(macOS, unavailable)
func bar() {
// Even though foo() and bar() are unavalable on macOS the compiler still
// strongly links foo().
foo()
}
```
This created an unnecessary dependency between libraries and their clients and
also can interfere with back deployment, since unavailable declarations may not
be present in a library on all OS versions. Developers could work around these
issues by conditionally compiling the code that references an unavailable
declaration, but they shouldn't have to given that unavailable code is meant to
be provably unreachable at runtime. Additionally, it could improve library code
size if we allowed the compiler to strip unavailable declarations from a binary
completely.
Resolves rdar://106673713
The `@MainActor` global actor constraint on a declaration does not carry an
inherent ABI impact and therefore use of this constraint should not be limited
to OS versions where Swift concurrency is available.
Resolves rdar://105610970
It shares many of the same values as OpenBSD (which both inherited from 4.4BSD),
and we wouldn't expect those to diverge due to the respective platforms'
bincompat goals.
Previously, when creating availability attributes for synthesized declarations
we would identify some set of reference declarations that the synthesized
declaration should be as-available-as. The availability attributes of the
reference declarations would then be merged together to create the attributes
for the synthesized declaration. The problem with this approach is that the
reference declarations themselves may implicitly inherit availability from their
enclosing scopes, so the resulting merged attributes could be incomplete. The
fix is to walk though the enclosing scopes of the reference declarations,
merging the availability attributes found at each level.
Additionally, the merging algorithm that produces inferred availability
attributes failed to deal with conflicts between platform specific and platform
agnostic availability. Now the merging algorithm notices when platform agnostic
availability should take precedence and avoids generating conflicting platform
specific attributes.
Resolves rdar://106575142
