This test occasionally fails due apparently not loading libswiftFoundation. The test relies on a bridging header to import the Foundation module, which seems iffy. Explicitly import Foundation instead.
rdar://114590327
These builds do not work outside of darwin currently. Rather than adding
the skip to all the necessary build presets, just disable in the product
instead.
This library served its purpose and has overstayed its welcome.
The library shipped in Xcode can't change again from the state it was
in, so changes to the sources here will not affect that library, which
is confusing. The library does not currently build due to changes in the
runtime headers, so it does not give meaningful signal to anything
anymore. If you need to test things in a backdeploy concurrency
environment, use the copy from the toolchain in Xcode as that will give
you a far clearer picture of what the code will actually be running with
than the state of the sources here did.
In https://github.com/apple/swift/pull/66560 , a bug in the lowering of
`global_addr` was fixed. Part of that fix was to postpone mapping the
type of the global into context until getting the address of the global
and projecting the buffer for the out-of-line value; at that point, the
type is mapped into context and the address is cast.
It introduced an issue for fixed-size globals, however: the type of such
globals was not mapped into context; the result was that the lowered
value set for the corresponding SIL value would have the wrong type.
Fix that by extracting the code which mapped the type into context and
cast the address to the appropriate lowered type into a lambda and call
that lambda both in both the fixed-size (newly) and non-fixed-size (as
before) cases.
rdar://114013709
A type variable that represents a key path literal cannot be bound
directly to `AnyKeyPath` or `PartialKeyPath`, such types could only
be used for conversions.
It used to be the task of the binding inference to infer `AnyKeyPath`
and `PartiaKeyPath` as a `KeyPath` using previously generated type
variables for a root and value associated with key path literal
(previously stored in the locator).
Recently we switched over to storing key path information in the
constraint system and introduced `resolveKeyPath` method to gain
more control over how key path type variable gets assigned.
Getting information from the constraint system creates a problem
for the inference because "undo" for some bindings would be run
after solver scope has been erased, so instead of modifying bindings
in `inferFromRelational`, let's do that in `resolveKeyPath` right
before the key path type variable gets bound which seems to be a
better place for that logic anyway.
Resolves: rdar://113760727
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
The original bug was a crash-on-invalid with a missing '}', but it
actually exposed a bug with nested protocols (SE-0404) and another
long-time bug.
- Whatever we do, we should skip this for protocols because their 'Self'
parameter is not bound from context.
- getTrailingWhereClause() is not the right proxy for "has a generic
signature different than its parent", in particular it doesn't
round-trip through serialization. Instead, just compare generic
signatures for pointer equality in the early return check.
The second change is source-breaking because it was possible to
write a nested type with a `where` clause and use it contradicting
its requirements across a module boundary.
Fixes rdar://113103854.
If type variable we are about to bind represents a pack
expansion type, allow the binding to happen regardless of
what the \c type is, because contextual type is just a hint
in this situation and type variable would be bound to its
opened type instead.
Resolves: rdar://112617922
Now that the SwiftStdlib 5.9 macro has been defined, this test failing
with stdlib debug builds is exposed. That is occurring because the back
deployment fallback
`$ss9TaskLocalC13withValueImpl_9operation4file4lineqd__xn_qd__yYaKXESSSutYaKlFTwB`
is now being called.
In unoptimized stdlib builds, the version of that function that is
deserialized into the test case module features an unoptimized copy of
the argument `%1` into a temporary (`%10`):
```
%10 = alloc_stack $Value // users: %14, %13, %11
copy_addr %1 to [init] %10 : $*Value // id: %11
// function_ref swift_task_localValuePush
%12 = function_ref @swift_task_localValuePush : $@convention(thin) <τ_0_0> (Builtin.RawPointer, @in τ_0_0) -> () // user: %13
%13 = apply %12<Value>(%9, %10) : $@convention(thin) <τ_0_0> (Builtin.RawPointer, @in τ_0_0) -> ()
dealloc_stack %10 : $*Value // id: %14
```
This is a problem because `swift_task_localValuePush` allocates in the
async stack (see rdar://107275872) but that fact isn't encoded in SIL
(the fix for which is tracked by rdar://108260399), so the
`alloc_stack`/`dealloc_stack` surrounding that call result in a
violation of stack discipline.
```
push // alloc_stack
push // swift_task_localValuePush
pop // dealloc_stack -- oops
```
In optimized stdlib builds, the copy has been optimized away by the time
the function is deserialized into the test case module:
```
bb0(%0 : $*R, %1 : $*Value, %2 : @guaranteed $@noescape @async @callee_guaranteed @substituted <τ_0_0> () -> (@out τ_0_0, @error any Error) for <R>, %3 : @guaranteed $String, %4 : $UInt, %5 : @guaranteed $TaskLocal<Value>):
// function_ref _checkIllegalTaskLocalBindingWithinWithTaskGroup(file:line:)
%6 = function_ref @$ss039_checkIllegalTaskLocalBindingWithinWithC5Group4file4lineySS_SutF : $@convention(thin) (@guaranteed String, UInt) -> () // user: %7
%7 = apply %6(%3, %4) : $@convention(thin) (@guaranteed String, UInt) -> ()
// function_ref TaskLocal.key.getter
%8 = function_ref @$ss9TaskLocalC3keyBpvg : $@convention(method) <τ_0_0 where τ_0_0 : Sendable> (@guaranteed TaskLocal<τ_0_0>) -> Builtin.RawPointer // user: %9
%9 = apply %8<Value>(%5) : $@convention(method) <τ_0_0 where τ_0_0 : Sendable> (@guaranteed TaskLocal<τ_0_0>) -> Builtin.RawPointer // user: %11
// function_ref swift_task_localValuePush
%10 = function_ref @swift_task_localValuePush : $@convention(thin) <τ_0_0> (Builtin.RawPointer, @in τ_0_0) -> () // user: %11
%11 = apply %10<Value>(%9, %1) : $@convention(thin) <τ_0_0> (Builtin.RawPointer, @in τ_0_0) -> ()
```
The argument `%1` is forwarded into the apply of `swift_task_localValuePush`.
rdar://112898559
IRGen crashed in case an enum, which has a 24 bit payload (e.g. three `UInt8`), is used as a payload of another enum, e.g. `Optional`, in a statically initialized global variable.
rdar://112823823
`same-shape` mismatch detection logic shouldn't expect that types are
always packs because they could be either invalid (i.e. Void) or pack
archetypes too.
Resolves: rdar://112090069
If the pattern doesn't have any pack parameters in it anymore,
we need to recover the substituted count type from the original
count type.
Fixes rdar://problem/112065340.
I earlier overhauled the enum layout logic to correctly consider
enums with generic cases and cases that have zero size.
This updates the enum projection logic to use that information
as well.
In particular, this fixes a bug where an MPE with zero-sized cases
would be incorrectly projected by RemoteMirror (with consequences
for the `leaks` tool and lldb).
Resolves rdar://111705059
The `_Backtracing` module has a number of private implementation only
imports that aren't used outside of the module and that don't require
any additional libraries (hence they aren't relevant to the outside
world). `verify_all_overlays.py` needs to know about these when it
does its test, because it loadas the module as the main module, which
results in implementation only imports being required instead of
ignored.
rdar://110261712
Previously we would wait until CSApply, which
would trigger their type-checking in
`coercePatternToType`. This caused a number of
bugs, and hampered solver-based completion, which
does not run CSApply. Instead, form a conjunction
of all the ExprPatterns present, which preserves
some of the previous isolation behavior (though
does not provide complete isolation).
We can then modify `coercePatternToType` to accept
a closure, which allows the solver to take over
rewriting the ExprPatterns it has already solved.
This then sets the stage for the complete removal
of `coercePatternToType`, and doing all pattern
type-checking in the solver.
