`FailureDiagnosis::visitUnresolvedMemberExpr` tries to use the same logic
as `diagnoseSingleCandidateFailures` so instead of doing that let's remove
some of the special handling and use `diagnoseSingleCandidateFailures`
directly instead, which improves label diagnostics and handles more erroneous
cases as well.
Resolves: rdar://problem/31898542
Swift 3 supported limited argument destructuring when it comes to
declaring (trailing) closures. Such behavior has been changed by
SE-0110. This patch aims to provide better error message as well
as fix-it (if structure of the expected and actual arguments matches)
to make the migration easier and disambiguate some of the common
mistakes.
Resolves: SR-4738, SR-4745, rdar://problem/31892961.
Previously situations like `self.foo(...)` wouldn't be considered as viable
for diagnosing the instance method on type calls, because the base wasn't
TypeExpr, which only accounts for e.g. `X.foo`, instead of validating base
expression itself this patch checks if the _type_ of base expression is
Metatype which is less restrictive.
Resolves: SR-4692.
Any ambiguity inside of a call with a trailing closure
call was going down the code path that would tell you to
add an argument label... but the ambiguity might not be
with the call that has the trailing closure itself, and
instead something inside.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
Some APIs that expected a String now expect a Substring and vice
versa. To ease the transition, emit fix-its on conversion errors
between these types that the migrator can pick up.
When converting from Substring -> String, suggest wrapping in
`String.init`.
When converting from String -> Substring, suggest appending the
void subscript `[]`. (This isn't implemented yet so this is
hidden behind a flag).
This can possibly be generalized later when converting between
some sequence and its subsequence, such as Array and ArraySlice,
for example.
rdar://problem/31665649
rdar://problem/31666638
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
This lets you match `case .foo` when `foo` resolves to any static member, instead of only a `case`, albeit without the exhaustiveness checking and subpattern capabilities of proper cases. While we're here, adjust the type system we set up for unresolved patterns embedded in expressions so that we give better signal in the error messages too.
After we call into typeCheckExpression() we need to cache the
resulting types in the constraint system type map because we later
call into code that reads the types out of the type map.
Fixes rdar://problem/30376186 as well as a couple crashers.
Storing this separately is unnecessary since we already
serialize the enum element's interface type. Also, this
eliminates one of the few remaining cases where we serialize
archetypes during AST serialization.
If there are unresolved generic parameters present and we are trying
to diagnose problems related to initializer call, it makes sense to
check argument expression first, which might be erroneous and then move
on to the ambiguity checking instead of trying to lookup possible
constructors directly.
Add additional checks before trying to re-check argument expression in
`FailureDiagnosis::diagnoseImplicitSelfErrors` and before trying to use
its resulting type, which can only be either tuple or paren type.
It's undesirable to have generic type which contains type variables
as contextual conversion type while diagnosing sub-expressions, it's
going to result in attempt to convert generic arguments to unresolved
type which produces worse diagnostics than no contextual type at all.
Resolves: SR-3525.
In Swift 4 mode, no longer consider e.g. 'nsNumber as Int' or 'nsValue as NSRange' to be valid coercions. This would break compatibility with Swift 3, so in Swift 3 mode, accept the coercion, but *also* accept a checked cast without a warning, and raise a migration warning about the unchecked coercion.
Refactor TypeChecker::checkGenericArguments to enable it
to be used by FailureDiagnosis::diagnoseArgumentGenericRequirements,
which consolidates requirement checking in one place.
