* [Sema] Implementing is runtime check always true diagnostic as a fix
* [AST] Implement getWithoutThrows on function type
* [CSSimplify] Detect that checked cast types conversion is always true and record warning fix
* [test] Some additional test cases for SR-13789
* [Sema] Fixing typo on fix name
* [Sema] Move and adjust the ConditionalCast diagnostics to the fix format
* [Sema] Remove some checked cast diagnostics from check constraints and move to fix
* [Sema] Renaming checked cast coercible types fix
* [Sema] Some adjustments and rewrite on the logic for downcast record fix
* [Sema] Move logic of runtime function type to AllowUnsupportedRuntimeCheckedCast::attempt
* [Sema] Abstract checked cast fix logic to static function and minor adjustments
* [Sema] Renamings from review
Generally, casting consistency demands that we be able
to extract anything from an existential that can be put
into that existential. (Which is why the casting spec
requires that casting permit arbitrary injection and
projection of optionals.)
This particular diagnostic prevented optionals from being
projected back out of existentials:
let i: Int?
let a: Any = i // Inject Int? into Any
// Error prevents projecting Int? back out of Any
a as? Int?
This also broke certain uses of Mirror (weak variables get reflected as
optionals stored in Any existentials).
This removes all calls to typesSatisfyConstraint() except for the
isConvertibleTo() check at the beginning, in the process making the
analysis a little bit more accurate.
This helps us to better diagnose failures related to generic
requirements like `T == [Int]` as well as protocol compositions,
which require deep equality check.
Since this kind of failure is really a conversion failure, let's
inherit from `Contextual{Mismatch, Failure}` which also helps with
storage for from/to types and their resolution.
Also let's use original types involved in conversion to form
this fix, which helps to perserve all of the original sugar.
This way it covers a lot more ground and doesn't conflict with
other fixes.
Another notable change is related to check for IUO associated
with source type, that covers cases like:
```swift
func foo(_ v: NSString!) -> String {
return v
}
```
Instead of general conversion failure check for IUO enables solver
to introduce force downcast fix.
Detect and diagnose a contextual mismatch between expected
collection element type and the one provided (e.g. source
of the assignment or argument to a call) e.g.:
```swift
let _: [Int] = ["hello"]
func foo(_: [Int]) {}
foo(["hello"])
```
- Many tests got broken because of two things:
- AST dump now outputs to stdout, but many tests expected stderr. This was a straightforward fix.
- Many tests call swift with specific parameters; specifically, many call `swift frontend` directly. This makes them go through the compiler in unexpected ways, and specifically it makes them not have primary files, which breaks the new AST dump implementation. This commit adds the old implementation as a fallback for those cases, except it dumps to `stdout` to maintain some consistence.
Finally, the `/test/Driver/filelists.swift` failed for unknown reasons. It seems its output now had some lines out of order, and fixing the order made the test pass. However, as the reasons why it failed are unknown, this fix might not have been a good idea. Corrections are welcome.
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.
`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
There are other parts of CSApply that attempt to peephole transform ArrayExprs (particularly bridging, which tries to turn `[x, y, ...] as T` into `[x as T, y as T, ...]`) and expect the elements to have already been rvalue-d. Fixes rdar://problem/40859007.
