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.
This could happen previously when computing the existential type
for a given archetype. In cases where an archetype is only constrained
to a class, return the class type directly rather than wrapping it
in an existential type.
`shouldCoerceToContextualType` used `solution.getType(ASTNode)`
which returns a type that has type variables in it. To properly
check whether result type needs a coercion it has to be resolved
first which is done via `solution.getResultType(ASTNode)`.
Resolves: rdar://88285682
The current check in MiscDiagnostics can only handle local 2-cycles as in:
func foo() -> some P { return bar() }
func bar() -> some P { return foo() }
Larger cycles, such as the 3-cycle present in the validation test in this patch cannot be detected without resolving all substitutions up front. Therefore, we take the tact that we can at least prevent the compiler from crashing. At runtime, instead, type resolution will blow out the stack.
The check here is simple: Plumb through a set of opaque type decls that the resolution machinery has already seen, and if we encounter a recursive opaque type substitution bail with the original opaque type.
rdar://87121502
