Currently edge related to the parameter bindings is contracted
without properly checking if newly created equivalence class has
the same inout & l-value requirements. This patch improves the
situation by disallowing contraction of the edges related to parameter
binding constraint where left-hand side has `inout` attribute set.
Such guarantees that parameter can get `inout` type assigned when
argument gets `l-value` type.
Resolves: rdar://problem/33429010
Since we no longer allow constraction of subtype constraints, workaround
which exists in `matchTypes`, for situations where left-hand side of such
constraint is going to be wrapped in `inout` type, is no longer required.
Resolves: rdar://problem/34137342, rdar://problem/34136625
Split out the things that are really specific to Swift 3 into a new
closures_swift3.swift.
In the process I found that two things that should compile without error
under -swift-version 4 do not, so those tests are currently in
closures_swift3.swift and I have opened new bugs for the issues:
https://bugs.swift.org/browse/SR-5791https://bugs.swift.org/browse/SR-5792
If we allow the right-hand type to be bound first, it can artificially
limit the options for the left-hand side, so attempt to delay binding of
the right-hand side types until after we've chosen something for the
left-hand side.
The test here will not fail without this change, but will fail without
this change if the ConstraintGraph.cpp changes from @xedin's edge
contraction patch (https://github.com/apple/swift/pull/11118) are
applied.
In diagnoseUnintendedOptionalBehavior, guard against recursing into
non-single-expression closures. If we recurse into these, we can end
up hitting malformed ASTs that we do not expect. These happen when we
successfully type-check the code outside of the closure, but the
closure body has errors.
There are potentially other similar issues in other miscellaneous
diagnostics walks.
I opened https://bugs.swift.org/browse/SR-5758 to remind us to review
these and ensure they do not have similar issues.
Previously, the failure diagnosis visitor would
default to the generic expr walk which would wind
up type checking the closure body and calling it a day.
Walk into the closure of a capture list expression to
emit better diagnostics.
A regression test for SR-5747 is added.
Implement and document `reduce(into:_:)`, with a few notes:
- The `initial` parameter was renamed `initialResult` to match the first parameter in `reduce(_:_:)`.
- The unnamed `combining` parameter was renamed `updateAccumulatingResult` to try and resemble the naming of the closure parameter in `reduce(_:_:)`.
- The closure throws and `reduce(into:_)` re-throws.
- This documentation mentions that `reduce(into:_)` is preferred over `reduce(_:_:)` when the result is a copy-on-write type and an example where the result is a dictionary.
Add benchmarks for reduce with accumulation into a scalar, an array, and a dictionary.
Update expected error message in closures test (since there are now two `reduce` methods, the diagnostic is different).
Calls involving single trailing closure arguments require special
handling because we don't have as much contextual information
about function/argument types as in with regular calls, which means
that diagnosing such situations only by `visitApplyExpr`
yields subpar results.
Resolves: SR-4836.
If the contextual closure type expects no parameters but N
parameters where used and all of the them are anonymous, let's
suggest removing them.
Resolves: rdar://problem/32432145
When matching inputs of a function type, be sure to
strip off ParenType sugar so that we don't end up
with ParenTypes in associated type witnesses.
This fixes various issues with SE-0110.
Fixes <rdar://problem/32214649>.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
The following code behaves incorrectly due to the presence of this
overload.
let a: Int = 1
let b: Int? = 2
let c: Int? = nil
let result: [Any] = [a, b, c].flatMap { $0 }
Fixes: <rdar://problem/31910642>
Due to implicit promotion to optional it is possible to call flatMap
with a closure, that does not return an optional. This way the code
works, but is unnecessary inefficient. Such uses of flatMap can and
should be replaced with map.
When trying to solve for the test case we attempt to simplify a value
member constraint and it fails because we've bound the LHS type
variable to an optional as a result of other constraints involving
other type variables in the equivalence class of this type
variable.
We don't have enough information to directly deduce the non-optional
type directly from other constraints involving this type variable.
This change results in one interesting type checking anomoly. In Swift
3 mode, we now successfully typecheck an expression that we previously
did not. Although the type checking technically makes sense given the
type checking rules we have in place, it can be a bit surprising to
users. Fortunately we emit a warning that calls out the surprising
behavior of considering an expression unused.
Fixes rdar://problem/30271695.
Previously we would check TMF_UnwrappingOptional flag, which does not
stick with the constraint, so it would not always persist. Now, add a
new OptionalPayload locator element, which is more correct.
Fixes <rdar://problem/30429709>.
`1 { }` was parsed as a call expression with a trailing closure. This made the diagnostics for `var x = 1 { get { ... } }` extremely bad. Resolves SR-3671.
We limit Optional-to-IUO as an implicit conversion to avoid making
common expressions ambiguous. However, this runs into trouble with
function-to-function conversions, which always look for a "Subtype"
relationship for their inputs and outputs. This is a conservative way
for Sema to avoid emitting conversions that SILGen cannot handle.
The problem case here is converting a closure with type '(Any!) ->
Void' to a value of type '(Any?) -> Void':
let f: ((Any?) -> Void) = { (arg: Any!) in }
This is clearly a safe conversion, since 'Any!' and 'Any?' have the
same representation at run time, but historically we've disallowed it
because of the above rules. However, in Swift 3.0 this particular case
was permitted, with the type checker deciding that the 'Any?' argument
to 'f' could first itself be put into an 'Any', then /that/ value
could go through a value-to-optional conversion to make 'Any!'.
Fortunately the emitted code didn't follow this incorrect conversion
path.
This patch doesn't even try to emulate the old behavior. Instead, it
just weakens the restriction on Optional-to-IUO via a new type
matching flag that only applies within the context of matching
function types.
We can consider opening up function conversions in Swift 4 to anything
that supports conversion---not just subtyping---now that SILGen knows
how to automatically reabstract most such things. But whether we do or
not, Optional/IUO is a special case.
https://bugs.swift.org/browse/SR-3758
Convert subtype constraints with inout on one side and type variable
on the other into fixed binding. Constriants like `inout T0 subtype T1`
where (T0 must be materializable) are created when closures are part
of the generic function parameters e.g. `func foo<T>(_ t: T, (inout T) -> Void) {}`
so when such function gets called e.g.
```
var x = 42
foo(x) { $0 = 0 }
```
it's going to try and map closure parameters type (inout T0) - where
is opened generic parameter T - to argument type (T1), which can
be 'inout' but it's uncertain at this stage, but since closure
'declaration' `{ $0 = 0 }` is wrapped inside of a function call,
it has to 'map' parameters to arguments instead of converting them,
see `ConstraintSystem::matchFunctionTypes`.
Resolves: SR-3520, SR-1976, SR-3073, SR-3479.
We have an implicit conversion where a closure with a non-Void
result type can be passed as a function value with a Void
result; this makes single-expression closures more usable in
the case where you want the single expression to be a
statement -- discarding it's result.
Unfortunately we were checking if the locator contains a
ClosureResult component *anywhere* in the path. This is too
permissive. The correct check is that the *last* path component
is a ClosureResult.
Otherwise, we happily convert anything to () *anywhere*
in a closure result, which crashes immediately in SILGen.
Fixes <https://bugs.swift.org/browse/SR-403>.
In Swift 3.0.1, argument labels are ignored when calling a function
having a single parameter of 'Any' type. That is, if we have:
func foo(_: Any) {}
Both of the following were accepted in a no-assert build (an assert
build would crash, but the GM builds of Xcode ship with asserts off):
foo(123)
foo(data: 123)
This behavior was fixed by 578e36a7e1,
but unfortunately we have to revert to the old behavior *and* defeat
the assertion when in Swift 3 mode.
Swift 4 mode still has the correct behavior, where the second call
'foo(data: 123)' produces a diagnostic.
Now, I have to pour myself a strong drink to forget this ever happened.
Fixes <rdar://problem/28952837>.
This reverts commit e172383e2f.
There were two problems with this commit:
- This was a source-breaking change and should have been feature-gated.
- It only addressed one narrow case of SE-0110.
Fixes <rdar://problem/28621719>.
When called with a ParenType wrapping a DependentMemberType,
we would drop the ParenType because we used type->getAs<ParenType>()
rather than dyn_cast<ParenType>(type.getPointer()).
This fixes an existing QoI issue with closure argument tuples,
and prevents another regression once SubstitutedType is removed.
This handles situation when overload for the subscript hasn't been resolved
by constraint solver, such might happen, for example, if solver was allowed to
produce solutions with free or unresolved type variables (e.g. when running diagnostics).
Resolves: <rdar://problem/27329076>, <rdar://problem/28619118>, <rdar://problem/2778734>.
