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 inside a declaration or extension of TypeName, humans usually don't write
the full typename like #selector(TypeName.foo), but instead prefer the neater
form #selector(self.foo). The compiler has enough information to do this too.
Fixes rdar://problem/2528469
Whenever we visit a declaration via the DeclChecker, add it to the
list of declarations to finalize. This makes sure that we can centralize
the notion of “finalize for SILGen” and that it will be called for
everything in the source file being processed.
When inside a declaration or extension of TypeName, humans usually don't write
the full typename like #selector(TypeName.foo), but instead prefer the neater
form #selector(self.foo). The compiler has enough information to do this too.
Fixes rdar://problem/25284692 .
Previously, bridging conversions were handled as a form of "explicit
conversion" that was treated along the same path as normal
conversions in matchTypes(). Historically, this made some
sense---bridging was just another form of conversion---however, Swift
now separates out bridging into a different kind of conversion that is
available only via an explicit "as". This change accomplishes a few
things:
* Improves type inference around "as" coercions. We were incorrectly
inferring type variables of the "x" in "x as T" in cases where a
bridging conversion was expected, which cause some type inference
failures (e.g., the SR-3319 regression).
* Detangles checking for bridging conversions from other conversions,
so it's easier to isolate when we're applying a bridging
conversion.
* Explicitly handle optionals when dealing with bridging conversions,
addressing a number of problems with incorrect diagnostics, e.g.,
complains about "unrelated type" cast failures that would succeed at
runtime.
Addresses rdar://problem/29496775 / SR-3319 / SR-2365.
We saw manual migration is necessary on these cases to add 'as Type'. This patch starts
to issue compiler fixits on return statement and initialization just like in other type-mismatch
cases.