This either became dead shortly after the removal of Swift 3
compatibility mode from the constraint solver, or even earlier.
Note that the code completion test change is actually correct
because (Any) -> () is not convertible to () -> () in the
language.
In some cases, such as when pushing a collection conversion down to per-element conversions, we'll coerce a subtype metatype to AnyObject, as in:
```
func f(_: [AnyObject]) {}
f([NSString.self, NSObject.self]) // Type checks as [NSObject.Type] converted to [AnyObject]
```
and only record the restriction kinds used in the indirect steps NSString -> NSObject and NSObject.Type -> AnyObject without recording the jump from NSString.Type to AnyObject. coerceToType ought to apply this subtyping rule even without such a hint, though, since the restriction kind is intended only as an optimization. Fixes rdar://problem/42666956 .
Aim of this new diagnostic abstraction is to encapsulate each
individual failure into its own class with some shared base.
Good example of this - diagnostics related to generic requirement
failures, where each kind (conformance, same-type etc.) has
some specific logic e.g. diagnostic message but the all share
the same traits like affected declaration/requirement.
Since information comes from `Solution` anyway, it's good to have
that logic localized, but it's also useful for diagnostics based on
fixes attached to solutions.
While trying to diagnose missing conformances don't attempt
to lookup parameter position if the parent apply expression
is not available, which could happen when fixes are produced
as part of the sub-expression diagnostics.
If fixes are allowed let solver record missing protocol conformance
requirements and assume that `conformsTo` constraint is successfully
solved, this helps to diagnose such errors without involving
heavy-weight expression based diagnostics.
Resolves: rdar://problem/40537858
Once you’ve called a function and retrieved a result, IRGen will want
layout information for the result type. Make sure that the type checker
precomputes it.
This makes sure that the diagnostics appear in the stable order
which is closer to what users would expect e.g. evaluation
order, otherwise, because disjunctions are currently attempted
based on their size, ordering of error messages produced by
applying fixes is completely arbitrary.
Let the solver disregard missing argument labels and record correct
ones, so such problem could be diagnosed later on iff there were no
other more serious failures.
Implementation is as follows: In `preCheckExpression` try to
detect if there is `T(literal)` call in the AST, replace it with
implicit `literal as T`, while trying to form type-checked AST,
after constraint solving, restore source information and drop
unnecessary coercion expression.
Resolves: rdar://problem/17088188
Resolves: rdar://problem/39120081
Resolves: rdar://problem/23672697
Resolves: rdar://problem/40379985
Instead of mixing flags between type-checker and constraint solver, let's
move the ones which are useful in constraint system there. Doing
so allows for `solveForExpression` to be moved from `TypeChecker` to
`ConstraintSystem` which consolidates solver logic.
It also allows to set these flags as part of constraint generation/solving,
which is sometimes important.
Replace the last (and most obscure) use of the poor “use ‘?’ or ‘!’” diagnostic with the
new, more explanatory version that provides separate notes with Fix-Its for coalescing or
force-unwrapping the value.
Finishes rdar://problem/42081852.
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.
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.
While trying to emit implicit load expression make sure that it's
done in a way where force/paren expression is always top level,
that leads to better fix-its and, in case of forcing, more compact
SIL by intermediate optional container.
Resolves: [SR-8150](https://bugs.swift.org/browse/SR-8150) / rdar://problem/41725207
`finish{Array,Dictionary}Expr` currently invoke `cs.cacheExprTypes` after building their semantic exprs, which in a nested collection expression, immediately undoes the type changes done by this peephole, leading to crashes due to inconsistencies in the AST later. rdar://problem/41040820
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
This is correct because it's the apparent rule used by CSSimplify:
value-to-autoclosure conversion is considered if and only if the
input type is not an autoclosure function type.
The real solution to this problem is that @autoclosure should be tracked
as a bit on the parameter type instead of as a bit on function types.
Slava has a PR leading towards that (https://github.com/apple/swift/pull/10094),
but it causes a source-compatibility problem when forwarding autoclosures.
You really shouldn't be able to forward autoclosures, but that's an
issue for the core team to resolve, and in the meantime there's this bug.
Fixes rdar://41219750.
