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>.
Modify TypeChecker::coerceParameterListToType to always validate and consider only
valid contextual types (contains: no undefined, error, or type variables etc.) for
argument type coercion, such logic prevents erasure of important explicitly specified
type information attached to parameters of the closure expressions being diagnosed.
Resolves: SR-2994.
In the constraint solver, we've traditionally modeled nested type via
a "type member" constraint of the form
$T1 = $T0.NameOfTypeMember
and treated $T1 as a type variable. While the solver did generally try
to avoid attempting bindings for $T1 (it would wait until $T0 was
bound, which solves the constraint), on occasion we would get weird
behavior because the solver did try to bind the type
variable.
With this commit, model nested types via DependentMemberType, the same
way we handle (e.g.) the nested type of a generic type parameter. This
solution maintains more information (e.g., we know specifically which
associated type we're referring to), fits in better with the type
system (we know how to deal with dependent members throughout the type
checker, AST, and so on), and is easier to reason able.
This change is a performance optimization for the type checker for a
few reasons. First, it reduces the number of type variables we need to
deal with significantly (we create half as many type variables while
type checking the standard library), and the solver scales poorly with
the number of type variables because it visits all of the
as-yet-unbound type variables at each solving step. Second, it
eliminates a number of redundant by-name lookups in cases where we
already know which associated type we want.
Overall, this change provides a 25% speedup when type-checking the
standard library.
As an extension of SR-2208 apply contextual conversion failure checking
to all of the expressions diagnosed via FailureDiagnosis::visitApplyExpr.
Resolves <rdar://problem/28909024>.
Always check arguments of the tuple type against corresponding parameters,
otherwise for a single argument functions e.g. foo(_ a: Any) after SE-0046
type checker is going to produce incorrect solution.
From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
- If a parameter type is a sugared function type, mark the type
as non-escaping by default. Previously, we were only doing this
if the parameter type was written as a function type, with no
additional sugar.
This means in the following cases, the function parameter type
is now non-escaping:
func foo(f: ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: Fn)
- Also, allow @escaping to be used in the above cases:
func foo(f: @escaping ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: @escaping Fn)
- Diagnose usages of @escaping in inappropriate locations, instead
of just ignoring them.
It is unfortunate that sometimes we end up desugaring the typealias,
but currently there are other cases where this occurs too, such as
qualified lookpu of protocol typealiases with a concrete base
type, and generic type aliases. A more general representation for
sugared types (such as an AttributedType sugared type) would allow
us to solve this in a more satisfactory manner in the future.
However at the very least this patch factors out the common code
paths and adds comments, so it shouldn't be too bad going forward.
Note that this is a source-breaking change, both because @escaping
might need to be added to parameters with a sugared function type,
and @escaping might be removed if it appears somewhere where we
do not mark function types as non-escaping by default.
This commit built upon the work of Pull Request 3895. Apart from the
work to make the following work
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
This patch also implement the part 2 mentioned in the #3895
```swift
let g: ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
Implements part of SE-0110. Single argument in closures will not be accepted if
there exists explicit type with a number of arguments that's not 1.
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
Note there's a second part of SE-0110 which could be considered additive,
which says one must add an extra pair of parens to specify a single arugment
type that is a tuple:
```swift
let g ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
This patch does not implement that part.
almost always the case that the user didn't know what the rules are between
single expression and multistatement closures, and they often don't know how to
fix the problem.
Address this by doing some heroics when we detect this situation. We now go dive
into the closure body, type check the explicit returns within it, and can usually
divine the right answer. When we do that, generate a fixit hint that generates a
modification to the existing signature, or synthesizes the entire signature from
scratch. This addresses:
<rdar://problem/22123191> QoI: multi-line closure with failure to infer result type should add a fixit
We previously produced the unhelpful error message:
x.swift:11:7: error: type of expression is ambiguous without more context
we now produce:
error: unable to infer closure return type in current context
which is going in the right direction.
Previously:
error: generic parameter 'T' could not be inferred
now:
error: unable to infer closure return type in current context
There is still more to do, but this fixes:
<rdar://problem/23570873> QoI: Poor error calling map without being able to infer "U" (closure result inference)
This flips the switch to have @noescape be the default semantics for
function types in argument positions, for everything except property
setters. Property setters are naturally escaping, so they keep their
escaping-by-default behavior.
Adds contentual printing, and updates the test cases.
There is some further (non-source-breaking) work to be done for
SE-0103:
- We need the withoutActuallyEscaping function
- Improve diagnostics and QoI to at least @noescape's standards
- Deprecate / drop @noescape, right now we allow it
- Update internal code completion printing to be contextual
- Add more tests to explore tricky corner cases
- Small regressions in fixits in attr/attr_availability.swift
Changes diangostic messages from referring specifically to @noescape,
which is going away, to 'non-escaping'. Introduces better diagnostics
and fixits for adding @escaping to closures that escape.
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
The reverts part of my previous patch. Removing the operators is too much of a
performance penalty to take. The difference is that the Strideable operators are
not transparent.
I still need to remove the UnsafeRawPointer operators, so -Onone performance
will be bad in some cases until this is fixed:
<rdar://problem/27513184> [perf] Strideable operators are not transparent. This is a huge -Onone performance penalty.
Generic versions of these functions are provided by Strideable.
This is required for SE-0107: UnsafeRawPointer. Otherwise, the presence
of non-generic operator overloads will conflict with existing operators
on String.
* Add UnsafeRawPointer type and API.
As proposed in SE-0107: UnsafeRawPointer.
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
The fundamental difference between Unsafe[Mutable]RawPointer and
Unsafe[Mutable]Pointer<Pointee> is simply that the former is used for "untyped"
memory access, and the later is used for "typed" memory access. Let's refer to
these as "raw pointers" and "typed pointers". Because operations on raw pointers
access untyped memory, the compiler cannot make assumptions about the underlying
type of memory and must be conservative. With operations on typed pointers, the
compiler may make strict assumptions about the type of the underlying memory,
which allows more aggressive optimization.
Memory can only be accessed by a typed pointer when it is currently
bound to the Pointee type. Memory can be bound to type `T` via:
- `UnsafePointer<T>.allocate(capacity: n)`
- `UnsafePointer<Pointee>.withMemoryRebound(to: T.self, capacity: n) {...}`
- `UnsafeMutableRawPointer.initializeMemory(as: T.self, at: i, count: n, to: x)`
- `UnsafeMutableRawPointer.initializeMemory(as: T.self, from: p, count: n)`
- `UnsafeMutableRawPointer.moveInitializeMemory(as: T.self, from: p, count: n)`
- `UnsafeMutableRawPointer.bindMemory(to: T.self, capacity: n)`
Mangle UnsafeRawPointer as predefined substitution 'Sv' for Swift void
pointer ([urp] are taken).
* UnsafeRawPointer minor improvements.
Incorporate Dmitri's feedback.
Properly use a _memmove helper.
Add load/storeBytes alignment precondition checks.
Reword comments.
Demangler tests.
* Fix name mangling test cases.
* Fix bind_memory specialization.
a match, since it *could* be, and typically conforms to whatever the expression is.
Fixing this improves the diagnostic in Constraints/closures.swift significantly, and
fixes these bugs:
<rdar://problem/21718970> QoI: [uninferred generic param] cannot invoke 'foo' with an argument list of type '(Int)'
<rdar://problem/21718955> Swift useless error: cannot invoke 'foo' with no arguments
where before we produced:
error: cannot invoke 'foo' with an argument list of type '(Int)'
and now produce:
x.swift:5:10: error: generic parameter 'A' could not be inferred
Whatever.foo(a: 23)
^
x.swift:1:7: note: 'A' declared as parameter to type 'Whatever'
class Whatever<A: IntegerArithmetic, B: IntegerArithmetic> {
^
Rather than using a specialized matching rule in the type checker that
depends on having default arguments in types, use call argument
matching consistently.
Note #1: This (correctly) breaks some existing code that depends on
inferring a parameter type of () for a single-argument parameter from
a no-argument function type().
Note #2: This pessimizes a code completion test, where the code
completion engine seems to depend on some quirks of argument
matching. The "type relationship" matching needs non-trivial work.
- Fix ExprTypeSaverAndEraser to save & restore the invalid bit on closure parameter decls.
- Teach CalleeCandidateInfo::evaluateCloseness to not try to find generic subs on types that
contain a unresolved type within them.
With these changes, the compiler doesn't segfault on the testcase when assertions are
enabled. It still doesn't produce a great diagnostic though.
Passing a function type to an @autoclosure param would always fail to
type check because of the attempt to decompose the parallel structure
of the two (both being functions). In this case, though, we don’t want
to do any such thing, we want to allow the ExprRewriter to explicitly
insert an AutoClosureExpr in coerceToType, as it would do with any
other non-function arg type.
Rearrange diagnoseGeneralConversionFailure to diagnose structural problems
even if we have some UnresolvedTypes floating around, then reject constraint
failures with UnresolvedTypes in them even harder. This keeps us giving
good errors about failures where we have a structural problem (with buried
irrelevant details) while not complaining about cases that are actually
ambiguous.
The end result of this is that we produce a lot better error messages in the
case of failed archetype inference. This also highlights the poor job we do
handling multi-stmt closureexprs...
