Currently if destination is unresolved instead of trying to re-typecheck
it again and diagnose structural problems which led to such outcome, it
gets completely ignored in favor of trying to type-check source without
contextual type. That leads to missed diagnostic opportunities, which
results in problems on AST verification and SIL generation stages, and
generally missleading errors e.g. `.x = 0`.
Resolves: SR-3506.
Recursive references of computed properties are allowed, but warned
about. Closures `var`s built like the one in 28396 should crash at
runtime, not crash the compiler.
This used to cause SILGen to capture and subsequently load `self` as a
constant. Then, when the super call was SILGen’d, it assumed that
`self` would be loaded Boxed. Diagnose before hitting SILGen so we
don’t have to pollute Lowering with code that handles `self` in this
odd position.
Crashers fixed are minor logic errors:
Patterns: Crash occurred when requesting the range of a created
Pattern. Validity of the range should be checked before returning it
to keep the entire range valid or invalid but never both.
ParseExpr/ParsePattern: The same fixes as the ones provided in #6319
CSDiag: The generic visitor needn’t look through TypeVarTypes either.
Marking such type variable as "must be materializable" is going to explicitly
enforce the notion that assignment destination type can only be materializable
and situations like source expression is InOutExpr are incorrect.
If T0 must be materializable and it's bound to T1, when matching T0 to
possibly optinal T1, look through optinality when setting materializability of the binding.
If return expression uses closure parameters, which have/are
type variables, such means that we won't be be able to
type-check result correctly and, unfornutately,
we are going to leak type variables from the parent
constraint system through declaration types.
In `checkTopLevelErrorHandling` if apply expression did not type-check,
don't attempt walking inside of it. This accounts for the fact that we don't
erase types without type variables to enable better code complication,
so DeclRefExpr(s) or ApplyExpr with DeclRefExpr as function contained
inside would have their types preserved, which makes classification
incorrect.
There might be erroneous typealiases present which re-define literal types,
so when trying to type-check something that supposed to confirm to erroneous
redeclaration by default, ignore it.
When running diagnostics for single expression closures,
explicitly disallow to produce solutions with unresolved type variables,
because there is no auxiliary logic which would handle that and it's
better to allow failure diagnosis to run directly on the closure body.
Currently isAnyHashableType method validates only structs but
it doesn't account for situation when type is represented via type
variable with type already fixed to AnyHashable, that results in
infinite loop in the solver because restriction [hashable-to-
anyhashable] is going to add new type variable recursively.
Instead of returning empty type when RValue destination of the assignment
could not be determined, let's return it unresolved directly instead and
let it be handled by coerceToType, which is going to produce special expression
(UnresolvedTypeConversionExpression) which facilitates better diagnostics.
Obtain type of the result expression without applying solutions,
because otherwise this might result in leaking of type variables,
since we are not reseting result statement and if expression is
sucessfully type-checked its type cleanup is going to be disabled
(we are allowing unresolved types), and as a side-effect it might
also be transformed e.g. OverloadedDeclRefExpr -> DeclRefExpr.
Add test case for crash triggered in `swift::TypeChecker::checkAutoClosureAttr`.
Current number of unresolved compiler crashers: 83 (5325 resolved)
/cc @slavapestov - just wanted to let you know that this crasher caused an assertion failure for the assertion `!typeInContext.isNull() && "no contextual type set yet"` added on 2016-12-15 by you in commit 757f253a3 :-)
Assertion failure in [`include/swift/AST/Decl.h (line 4121)`](https://github.com/apple/swift/blob/master/include/swift/AST/Decl.h#L4121):
```
Assertion `!typeInContext.isNull() && "no contextual type set yet"' failed.
When executing: swift::Type swift::VarDecl::getType() const
```
Assertion context:
```
}
/// Get the type of the variable within its context. If the context is generic,
/// this will use archetypes.
Type getType() const {
assert(!typeInContext.isNull() && "no contextual type set yet");
return typeInContext;
}
/// Set the type of the variable within its context.
void setType(Type t);
```
Stack trace:
```
0 0x0000000003500d48 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/path/to/swift/bin/swift+0x3500d48)
1 0x0000000003501486 SignalHandler(int) (/path/to/swift/bin/swift+0x3501486)
2 0x00007f6d5d5143e0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x113e0)
3 0x00007f6d5bc42428 gsignal /build/glibc-Qz8a69/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
4 0x00007f6d5bc4402a abort /build/glibc-Qz8a69/glibc-2.23/stdlib/abort.c:91:0
5 0x00007f6d5bc3abd7 __assert_fail_base /build/glibc-Qz8a69/glibc-2.23/assert/assert.c:92:0
6 0x00007f6d5bc3ac82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
7 0x0000000000ce3665 swift::TypeChecker::checkAutoClosureAttr(swift::ParamDecl*, swift::AutoClosureAttr*) (/path/to/swift/bin/swift+0xce3665)
8 0x0000000000ce2e47 swift::TypeChecker::checkTypeModifyingDeclAttributes(swift::VarDecl*) (/path/to/swift/bin/swift+0xce2e47)
9 0x0000000000d325ba swift::TypeChecker::typeCheckParameterList(swift::ParameterList*, swift::DeclContext*, swift::OptionSet<swift::TypeResolutionFlags, unsigned int>, swift::GenericTypeResolver&) (/path/to/swift/bin/swift+0xd325ba)
10 0x0000000000d2c43a checkGenericFuncSignature(swift::TypeChecker&, swift::ArchetypeBuilder*, swift::AbstractFunctionDecl*, swift::GenericTypeResolver&) (/path/to/swift/bin/swift+0xd2c43a)
11 0x0000000000d2b79e swift::TypeChecker::validateGenericFuncSignature(swift::AbstractFunctionDecl*) (/path/to/swift/bin/swift+0xd2b79e)
12 0x0000000000d1615b (anonymous namespace)::DeclChecker::visitFuncDecl(swift::FuncDecl*) (/path/to/swift/bin/swift+0xd1615b)
13 0x0000000000d05c00 (anonymous namespace)::DeclChecker::visit(swift::Decl*) (/path/to/swift/bin/swift+0xd05c00)
14 0x0000000000d13bbb (anonymous namespace)::DeclChecker::visitProtocolDecl(swift::ProtocolDecl*) (/path/to/swift/bin/swift+0xd13bbb)
15 0x0000000000d05be0 (anonymous namespace)::DeclChecker::visit(swift::Decl*) (/path/to/swift/bin/swift+0xd05be0)
16 0x0000000000d059c3 swift::TypeChecker::typeCheckDecl(swift::Decl*, bool) (/path/to/swift/bin/swift+0xd059c3)
17 0x0000000000c1e1b5 swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int, unsigned int) (/path/to/swift/bin/swift+0xc1e1b5)
18 0x0000000000992086 swift::CompilerInstance::performSema() (/path/to/swift/bin/swift+0x992086)
19 0x000000000047c5aa swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) (/path/to/swift/bin/swift+0x47c5aa)
20 0x000000000043ade7 main (/path/to/swift/bin/swift+0x43ade7)
21 0x00007f6d5bc2d830 __libc_start_main /build/glibc-Qz8a69/glibc-2.23/csu/../csu/libc-start.c:325:0
22 0x0000000000438229 _start (/path/to/swift/bin/swift+0x438229)
```
Otherwise, overload resolution and CSDiag disagree on what a viable
candidate is, so we can end up in a situation where the OverloadDeclRefExpr
has a concrete type that doesn't match the argument list in an ApplyExpr,
which causes a crash in CSDiag.
