This effectively reverts 6823744779
The blanket removal of isolation in default-value expressions had
unintented consequences for important workflows. It's still
a problem that needs to be addressed, but we need to be more precise
about the problematic situations.
Fixes a crash during diagnostics by not assuming that optional chain
would always produce an optional type, which is not true because in
error scenarios it could get assigned an invalid type from context.
Resolves: rdar://85516390
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.
`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>
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.
`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
With multi-statement closure inference enabled "outer candidates"
hack needs to be careful with its use of `isInvalid()` because some
of the declarations lookup finds might be coming from a multi-statement
closure that being type-checked, such declarations have to be avoided
as candidates, otherwise calling `isInvalid` on them results in a circular
type-checking.
Resolves: rdar://85843677
Allow `LinkedExprAnalyzer` to capture `??` operator and walk into
its arguments because they could have valuable type information,
but don't attempt to favor or link operators if `??` is present in a chain.
Resolves: rdar://85277993
exponential behavior.
Binding value types early allows the previous version of this test
to compile, but the performance still doesn't scale with a few more
operands in the + chain.
If a type variable has a subtype binding which came from a conversion/subtype/equality
constraint to a struct or enum (expect to `AnyHashable`, `Unsafe{Mutable}RawPointer`),
attempt it early because that type is the only choice which is not going to fail such
constraint.
For example, in cases like `$T argument convertible to Int` type variable could
only be bound to `Int`, `Int!`, or `@lvalue Int` to satisfy that constraint, so
it would make sense to attempt to bind it to `Int` early if it doesn't represent
a result of a member lookup (that's how IUO and/or `@lvalue` could be inferred)`
and doesn't have any direct disjunction associated with it e.g. for coercion or
optional matching.
`init` calls to redeclared types would end up diagnosed as ambiguity,
so locator simplification needs to account for the fact that "base"
of constructor might be overloaded type reference.
Resolves: rdar://84879566
In situations like `_ = ... as! Bool!` the `to` type could either
be represented by an optional (default) or unwrapped. Coercion warnings
cannot assume that `to` (even though its IUO) is always represented
as an optional type.
Resolves: rdar://83072606
This test only happened to be under the constraint system thresholds,
but the performance was not fast. Add a few operands to the + chain,
and disable shrink to push the solver past the performance thresholds.
Detect situations when type of a declaration hasn't been resolved yet
(one-way constraints would use a type variable to represent a type of IUO pattern),
and use additional type variable and a constraint to represent an
object type of a future optional type.
Resolves: SR-14893
Resolves: rdar://80271666
Typed patterns are represented by a name and a fixed contextual
type, let's not use intermediary type variable and one-way constraint
as its type because that variable would be bound right away to
contextual type. Also setting type of a variable declaration
to a type variable when contextual type is IUO doesn't play well
with overload resolution because it expects an optional type for
declarations with IUO attribute.
Resolves: rdar://80271666
If solutions either have no fixes at all or all of the are warnings,
let's use `diagnoseAmbiguity` to diagnose such cases as-if there are
no fixes at all.
Resolves: rdar://79657350
Use `findSelectedOverloadFor` instead of `findResolvedMemberRef`
to cover cases where member is found via base type unwrap, otherwise
conformance constraint would be re-inserted but never re-attempted
which results in a compiler crash.
Resolves: rdar://79268378
