If you have something like
protocol P {
typealias A = C
associatedtype T : A
}
class C {}
Then ::Structural resolution of 'A' in the inheritance clause will
produce a DependentMemberType 'Self.A'. Check for this case and
attempt ::Interface resolution to get the correct underlying type.
Fixes rdar://problem/90219229.
After https://github.com/apple/swift/pull/40793, alloc_boxes all have
their lifetimes protected by a lexical borrow scope. In that PR, DI had
been updated to see through begin_borrow instructions from a project_box
to a mark_uninitialized. It did not, however, correct the end_borrow
instructions when destroy_values of mark_uninitializeds were replaced
with destroy_addrs of project_boxes. That is done here.
In a bit more detail, in the following context
%box = alloc_box
%mark_uninit = mark_uninitialized %box
%lifetime = begin_borrow [lexical] %mark_uninit
%proj_box = project_box %lifetime
When it is not statically known whether a field is initialized, we are
replacing the instruction
// before
destroy_value %mark_uninit
// after
with the following diamond
// before
%initialized = load
cond_br %initialized, yes, no
yes:
destroy_addr %proj_box
br bottom
no:
br bottom
bottom:
dealloc_box %box
br keep_going
keep_going:
// after
Doing so is problematic, though, because by SILGen construction the
destroy_value is always preceded by an end_borrow:
end_borrow %lifetime
destroy_value %mark_uninit
Previously, that end_borrow remained above the
%initialized = load
instruction in the above. That was invalid because the the newly
introduced
destroy_addr %proj_box
was a use of the borrow scope (%proj_box is a projection of the
begin_borrow) and consequently must be within the borrow scope.
Note also that it would not be sufficient to simply emit the diamond
before the end_borrow. The end_borrow must come before the destruction
of the value whose lifetime it is protecting (%box), and the diamond
contains the instruction to destroy that value (dealloc_box) in its
bottom block.
To resolve this issue, just move the end_borrow instruction from where
it was to before the dealloc box. (This is actually done by moving it to
the top of the diamond's "continue" block prior to the emission of that
dealloc_box instruction.)
rdar://89984216
There are three kinds of invariant 'Self' uses here:
- 'Self' appears as the left hand side of a same-type requirement between type parameters
- 'Self' appears as a structural component of the right hand side of a concrete type requirement
- 'Self' appears as a structural component of the right hand side of a superclass requirement
My previous fix only handled the first case. Generalize it to handle all three.
Fixes rdar://problem/74944514.
The problem is that we currenly cannot represent the generic signature of
values of type `any P<some P>`. This is because we wind up producing
<Self where Self : P, Self.T == (some P)>
What we'd like to do in the future is erase the errant (some P) with
a fresh generic parameter and keep a substitution map on the side that
records the opaque type constraint. Something like
<Self, Opaque1 where Self : P, Opaque1 : P, Self.T == Opaque1> where Opaque1 == (some P)
The main point of this change is to make sure that a shared function always has a body: both, in the optimizer pipeline and in the swiftmodule file.
This is important because the compiler always needs to emit code for a shared function. Shared functions cannot be referenced from outside the module.
In several corner cases we missed to maintain this invariant which resulted in unresolved-symbol linker errors.
As side-effect of this change we can drop the shared_external SIL linkage and the IsSerializable flag, which simplifies the serialization and linkage concept.
`one-way` constraints disable some optimizations related to component
selection because they imply strict ordering. This is a problem for
multi-statement closures because variable declarations could involve
complex operator expressions that rely on aforementioned optimizations.
In order to fix that, let's move away from solving whole pattern binding
declaration into scheme that explodes such declarations into indvidual
elements and inlines them into a conjunction.
For example:
```
let x = 42, y = x + 1, z = (x, test())
```
Would result in a conjunction of three elements:
```
x = 42
y = x + 1
z = (x, test())
```
Each element is solved indepedently, which eliminates the need for
`one-way` constraints and re-enables component selection optimizations.
There is an edge case where the Requirement Machine produces a different
minimal signature than the GenericSignatureBuilder:
protocol P {
associatedtype X where X == Self
}
class C : P {
typealias X = C
}
<T where T : P, T : C>
The GenericSignatureBuilder produces <T where T == C> and the Requirement
Machine produces <T where T : C>. The new interpretation makes more sense
with the 'concrete contraction' pre-processing pass that is done now.
The GenericSignatureBuilder's interpretation is slightly more correct,
however the entire conformance is actually invalid if the class is not
final, and we warn about it now.
I'm going to see if we can get away with this minor ABI change without
breaking anything.
This avoids feeding invalid type parameters to the Requirement Machine
when a protocol requirement looks similar to a protocol requirement in
the inherited protocol but has an incompatible type.
Fixes https://bugs.swift.org/browse/SR-15826 / rdar://problem/89641535.
See the comment at the top of ConcreteContraction.cpp for a detailed explanation.
This can be turned off with the -disable-requirement-machine-concrete-contraction
pass, mostly meant for testing. A few tests now run with this pass both enabled
and disabled, to exercise code paths which are otherwise trivially avoided by
concrete contraction.
Fixes rdar://problem/88135912.
This adds a new reflection record type carrying spare bit information for multi-payload enums.
The compiler includes this for any type that might need it in order to accurately reflect the contents of the enum. The RemoteMirror library will use this if present to determine how to project the contents of the enum. If not present (for example, in older binaries), the RemoteMirror library falls back on an internal calculation of the spare bitmask.
A few notes:
* The internal calculation is not perfect. In particular, it does not support MPEs that contain other enums (e.g., optionals). It should accurately refuse to project any MPE that it does not correctly support.
* The new reflection field is designed to be expandable; this might someday avoid the need for a new section.
Resolves rdar://61158214
`repairFailures` needs a special case when l-value conversion is
associated with a result type of subscript setter because otherwise
it falls through and treats result type as if it's an argument type,
which leads to crashes.
Resolves: rdar://84580119
* [WIP] Initial draft at v2 Clock/Instant/Duration
* Ensure the literal types for _DoubleWide are able to be at least 64 bits on 32 bit platforms
* static cast timespec members to long
* Remove runtime exports from clock functions
* Export clock functions in implementations as they are in headers
* Clean up internal properties by adding leading underscores, refine availability to a TBD marker macro, and break at 80 lines to match style
* Shift operators to concrete Instant types to avoid complexity in solver resolution
* Adjust diagnostic note and error expectation of ambiguities to reflect new potential solver (perhaps incorrect) solutions
* Update stdlib/public/Concurrency/TaskSleep.swift
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
* [stdlib][NFC] Remove trailing whitespace
* [stdlib] Remove _DoubleWidth from stdlib's ABI
* [stdlib] Strip downd _DoubleWidth to _[U]Int128
* Additional adjustments to diagnostic notes and errors expectation of ambiguities to reflect new potential solver (perhaps incorrect) solutions
* Disable type checker performance validation for operator overload inferences (rdar://33958047)
* Decorate Duration, DurationProtocol, Instant and clocks with @available(SwiftStdlib 9999, *)
* Restore diagnostic ambiguity test assertion (due to availability)
* Add a rough attempt at implementing time accessors on win32
* Remove unused clock id, rename SPI for swift clock ids and correct a few more missing availabilities
* remove obsolete case of realtime clock for dispatch after callout
* Use the default implementation of ~ for Int128 and UInt128
* Ensure diagnostic ambiguitiy applies evenly to all platforms and their resolved types
* Restore the simd vector build modifications (merge damage)
* Update to latest naming results for Instant.Duration
* Updates to latest proposal initializers and accessors and adjust encoding/decoding to string based serialization
* Update availability for Clock/Instant/Duration methods and types to be 5.7
* Correct *Clock.now to report via the correct runtime API
* Ensure the hashing of Duration is based upon the attoseconds hashing
* Avoid string based encoding and resort back to high and low bit encoding/decoding but as unkeyed
* Adjust naming of component initializer to use suffixes on parameters
* Duration decoding should use a mutable container for decoding
* fix up components initializer and decode access
* Add platform base initializers for timespec and tiemval to and from Duration
* Add some first draft documentation for standard library types Duration, DurationProtocol and InstantProtocol
* Another round of documentation prose and some drive-by availability fixes
* InstantProtocol availability should be 5.7
* Correct linux timeval creation to be Int and not Int32
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
Based on its argument names and messages, `expectEqual` and friends expects the expected value of the calculation being tested to be provided as its first argument, and the actual value as the second:
```
expectEqual(4, 2 + 2)
```
This does not always match actual use -- folks like myself find the opposite ordering far more natural:
```
expectEqual(2 + 2, 4)
```
`expectEqual` currently uses the `expected`/`actual` terminology in its failure messages, causing confusion and needless suffering.
Change `expectEqual`'s declaration and error messages to use a naming scheme that does not assume specific roles for the two arguments. (Namely, use `first`/`second` instead of `expected`/`actual`.)
An alternative way to solve this would be to use argument labels, as in `expectEqual(expected: 4, actual: 2 + 2)`, or to introduce some sort of expression builder scheme such as `expect(2 + 2).toEqual(2)`. These seem needlessly fussy and overly clever, respectively.
