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.
Previously all of the following would strip off varying amounts of
MetatypeType, LValueType, InOutType, DynamicSelfType, etc:
- ConstraintSystem::performMemberLookup()
- ConstraintSystem::lookupMember()
- TypeChecker::lookupMember()
- DeclContext::lookupQualified()
- Type::getContextSubstitutions()
The problem is that the higher level methods that took a lookup type
would call the lower level methods, and post-process the result using
the given lookup type. Since different levels of sugar were stripped,
it made the code hard to reason about and opened up edge cases, eg
if a DynamicSelfType or InOutType appears where we didn't expect it.
Since filtering out static/instance and mutating/nonmutating members
is done at higher levels, there's no reason for these name lookup
operations to accept anything other than nominal types, existentials
and archetypes.
Make this so with assertions, and deal with the fallout.
- TypeMatchVisitor doesn't like seeing ErrorTypes -- stop if we have one.
- Common logic for replacing type parameters and variables with
UnresolvedType.
- Fix crash in coerceToType() if one of the two types has an UnresolvedType
in it, but not at the top level.
Fixes one compiler_crasher and some regressions with upcoming patches.
Not sure why but this was another "toxic utility method".
Most of the usages fell into one of three categories:
- The base value was always non-null, so we could just call
getCanonicalType() instead, making intent more explicit
- The result was being compared for equality, so we could
skip canonicalization and call isEqual() instead, removing
some boilerplate
- Utterly insane code that made no sense
There were only a couple of legitimate uses, and even there
open-coding the conditional null check made the code clearer.
Also while I'm at it, make the SIL open archetypes tracker
more typesafe by passing around ArchetypeType * instead of
Type and CanType.