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.
When emitting a diagnostic, mark the TypeRepr as invalid and
return an ErrorType to ensure that the diagnostic is not
emitted again, and to muffle downstream diagnostics.
This patch delays the removal of redundant isolation for inferred
global-actor isolation to Swift 6 too, since we only warn about it
changing in Swift 5. Otherwise, only isolation that is a byproduct
of inference no longer needs an await, which will probably confuse
people.
This change is with respect to SE-327, which argues that the
non-static stored properties of ordinary structs do not need
global-actor isolation.
If a struct is a property-wrapper, then global-actor isolation
still applies to the `wrappedValue`, even if it's a stored property.
This is needed in order to support the propagation of global-actor
isolation through the wrapper, even when the programmer has opted
to use a stored property instead of a computed one for the
`wrappedValue`. Since this propagation is a useful pattern, I think
this exception is reasonable.
