- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
A lot of operators (and most likely regular functions a well) have
overloads that accept i.e. a generic parameter that conforms to
`StringProtocol`, so the best fix in situations when argument is
a raw representable type would be to check whether `.rawValue`
conforms to the expected protocol and use it if so.
Resolves rdar://problem/75367157
* [CSDiagnostics] Adjusting MemberAccessOnOptionalBaseFailure to be able to handle key path component member base types
* [tests] Adding regression tests for SR-5688
* [CSDiagnostics] Adjusting source range to diagnose/insert the fixes in correct location
* [tests] Adjusting regression tests to handle the fixits
* [AST] Creating an helper getSourceRange function for KeyPathExpr::Component
* [ConstraintSystem] Store member base type when recording UnwrapOptionalBase fix
* [AST] Creating a new diagnostic note for removing optional from written type
* [CSDiagnostics] Adjusting logic around MemberAccessOnOptionalBaseFailure to emit the correct diagnostics and fixes
* [tests] Adjusting regression tests to add subscript and key path root cases with respective diagnostics
* [Diagnostics] Adjusting message to mention base type
* [CSDiagnostics] Better naming for method/variable that represents base source range
* [CSDiagnostics] Adjusting to use the stored base member only when member is a key path component.
* [Diagnostics] Adjusting minor typos and code
* [AST] Adjusting keypath root diagnostic note message for use unwrapped type
* [CSDiagnostics] Adjusments in MemberAccessOnOptionalBaseFailure diagnostics as per suggestion
* [tests] Adding more test cases for SR-5688
* [CSDiagnostics] Adjusting fixits for key path root and range for diagnostics
* [CSSimplify] Attempt to diagnose InsertExplicitCall for optional function return types when possible on simplifyOptionalObjectConstraint
* [tests] Adding TODO to improve the diagnostics refering to key path root infered as optional types
* [CSDiagnostics] Adjusting comments
* [CSSimplify] Adjusting logic on simplifyOptionalObjectConstraint to attempt InsertCall fix before remove unwrap
* [CSDiagnostics] Adjust the logic to use resolveType on MemberAccessOnOptionalBaseFailure construction
Single-expression closures have always been traversed differently
from multi-statement closures. The former were traversed as if the
expression was their only child, skipping the BraceStmt and implicit
return, while the later was traversed as a normal BraceStmt.
Unify on the latter treatment, so that traversal
There are a few places where we unintentionally relied on this
expression-as-child behavior. Clean those up to work with arbitrary
closures, which is an overall simplification in the logic.
Some of the diagnostics have special rules about anchor location,
let's make `getAnchor` virtual and allow sub-class to override
default implementation.
Previously we could skip default literal or
supertype bindings if we had already found a solution
with fixes, which could lead us to miss bindings
that produce better diagnostics.
Tweak the logic such that we continue exploring if
we're in diagnostic mode.
Resolves SR-12399.
If there are any conversion restrictions present while trying to repair
failures related to contextual type, let's give `simplifyRestrictedConstraintImpl`
a chance to run and fix the problem.
Resolves: rdar://problem/59773317
When applying the set of fixes introduced by a solution, don't rely on
a walk from the "root" expression of the constraint system to
attribute the fixes to expressions. Rather, collect the fixes and emit
diagnostics in source order of the expressions that pertain to.
Currently we only produce a fix if function type doesn't have any
parameters, but it should also account for function having defaults
for all of its parameters which would still allow for nullary call.
Currently even when `reconstituteSugar`'s `Recursive` parameter is set
to `true`, we stop rebuilding sugar upon hitting a desugared type. For
example `Optional<Optional<Int>>` will only be re-sugared to
`Optional<Int>?`. This commit changes the behaviour so we continue
recursing into the generic argument.
Now covers following new areas (alongside simple assignments):
- Contextual type coercions:
- In assignment e.g. `let _: X = foo`
- In return type positions e.g. `func foo() -> A { return bar }`
- Argument-to-parameter applications (including @autoclosure)
If the source of the assignment is a function type which has
a result that could be converted to expected destination type,
let's diagnose that as missing call if such function doesn't
have any parameters.
* Make sure that base and unwrapped types aren't null
* Don't allocate `ForceOptional` fix if nothing has been unwrapped
in `simplifyApplicableFnConstraint`
* Add sugar reconstitution support to `FailureDiagnostic::resolveType`
* Format diagnostics a bit better
Pass constraint system down into offering force unwrap fixits so that we can identify the type of the last member chosen for an optional chain. If there's a chain and the last member's return type isn't optional, then it's cleaner to offer to change that last '?' into a '!' to perform the force, rather than parenthesize the whole expression and force the result.
Introduce a new fix kind into the constraint solver to cover unwrapping the base
of a member access so we can refer to the a member of the unwrapped base.
Wire this fix kind to the just-added diagnostic that suggests either the
chaining ‘?’ or the force-unwrap ‘!’ via separate, descriptive Fix-Its.
Example:
error: value of optional type 'X?' must be unwrapped to refer to member 'f' of wrapped base type 'X'
let _: Int = x.f()
^
note: chain the optional using '?' to access member 'f' only for non-'nil' base values
let _: Int = x.f()
^
?
note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
let _: Int = x.f()
^
!
Before this, we would sometimes get a Fix-It for just ‘?’ and sometimes get a Fix-It for the
coalescing ‘??’, neither of which is likely to be right.
More work on rdar://problem/42081852.
Improve diagnostics when referencing a member of an optional base, where the
Optional type does not have the member but the wrapped type does. Specifically,
suggest both the chaining ‘?’ and the force-unwrapping ‘!’ Fix-Its via explanatory
notes, e.g.:
error: value of optional type '[Int]?' must be unwrapped to refer to member 'subscript' of wrapped base type '[Int]'
return foo.array[0]
^
note: chain the optional using '?' to access member 'subscript' only for non-'nil' base values
return foo.array[0]
^
?
note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
return foo.array[0]
^
!
More of rdar://problem/42081852.
When we determine that an optional value needs to be unwrapped to make
an expression type check, use notes to provide several different
Fix-It options (with descriptions) rather than always pushing users
toward '!'. Specifically, the errors + Fix-Its now looks like this:
error: value of optional type 'X?' must be unwrapped to a value of
type 'X'
f(x)
^
note: coalesce using '??' to provide a default when the optional
value contains 'nil'
f(x)
^
?? <#default value#>
note: force-unwrap using '!' to abort execution if the optional
value contains 'nil'
f(x)
^
!
Fixes rdar://problem/42081852.
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
Currently some contextual errors are discovered too late
which leads to diagnostics of unrelated problems like argument
mismatches, these changes attempt to improve the situation
and try to diagnose contextual errors related to calls
before everything else.
Resolves: SR-5045, rdar://problem/32934129
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
This removes conformance of DarwinBool and ObjCBool to the Boolean protocol,
and makes the &&/||/! operators be concrete w.r.t. Bool instead of abstract
on Boolean.
This fixes some outstanding bugs w.r.t diagnostics, but exposes some cases
where an existing diagnostic is not great. I'll fix that in a later patch
(tracked by rdar://27391581).
