These changes make the following improvements to how we generate diagnostics for expression typecheck failure:
- Customizing a diagnostic for a specific expression kind is as easy as adding a new method to the FailureDiagnosis class,
and does not require intimate knowledge of the constraint solver’s inner workings.
- As part of this patch, I’ve introduced specialized diagnostics for call, binop, unop, subscript, assignment and inout
expressions, but we can go pretty far with this.
- This also opens up the possibility to customize diagnostics not just for the expression kind, but for the specific types
involved as well.
- For the purpose of presenting accurate type info, partially-specialized subexpressions are individually re-typechecked
free of any contextual types. This allows us to:
- Properly surface subexpression errors.
- Almost completely avoid any type variables in our diagnostics. In cases where they could not be eliminated, we now
substitute in "_".
- More accurately indicate the sources of errors.
- We do a much better job of diagnosing disjunction failures. (So no more nonsensical ‘UInt8’ error messages.)
- We now present reasonable error messages for overload resolution failures, informing the user of partially-matching
parameter lists when possible.
At the very least, these changes address the following bugs:
<rdar://problem/15863738> More information needed in type-checking error messages
<rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
<rdar://problem/16449805> Wrong error for struct-to-protocol downcast
<rdar://problem/16699932> improve type checker diagnostic when passing Double to function taking a Float
<rdar://problem/16707914> fatal error: Can't unwrap Optional.None…Optional.swift, line 75 running Master-Detail Swift app built from template
<rdar://problem/16785829> Inout parameter fixit
<rdar://problem/16900438> We shouldn't leak the internal type placeholder
<rdar://problem/16909379> confusing type check diagnostics
<rdar://problem/16951521> Extra arguments to functions result in an unhelpful error
<rdar://problem/16971025> Two Terrible Diagnostics
<rdar://problem/17007804> $T2 in compiler error string
<rdar://problem/17027483> Terrible diagnostic
<rdar://problem/17083239> Mysterious error using find() with Foundation types
<rdar://problem/17149771> Diagnostic for closure with no inferred return value leaks type variables
<rdar://problem/17212371> Swift poorly-worded error message when overload resolution fails on return type
<rdar://problem/17236976> QoI: Swift error for incorrectly typed parameter is confusing/misleading
<rdar://problem/17304200> Wrong error for non-self-conforming protocols
<rdar://problem/17321369> better error message for inout protocols
<rdar://problem/17539380> Swift error seems wrong
<rdar://problem/17559593> Bogus locationless "treating a forced downcast to 'NSData' as optional will never produce 'nil'" warning
<rdar://problem/17567973> 32-bit error message is really far from the mark: error: missing argument for parameter 'withFont' in call
<rdar://problem/17671058> Wrong error message: "Missing argument for parameter 'completion' in call"
<rdar://problem/17704609> Float is not convertible to UInt8
<rdar://problem/17705424> Poor error reporting for passing Doubles to NSColor: extra argument 'red' in call
<rdar://problem/17743603> Swift compiler gives misleading error message in "NSLayoutConstraint.constraintsWithVisualFormat("x", options: 123, metrics: nil, views: views)"
<rdar://problem/17784167> application of operator to generic type results in odd diagnostic
<rdar://problem/17801696> Awful diagnostic trying to construct an Int when .Int is around
<rdar://problem/17863882> cannot convert the expression's type '()' to type 'Seq'
<rdar://problem/17865869> "has different argument names" diagnostic when parameter defaulted-ness differs
<rdar://problem/17937593> Unclear error message for empty array literal without type context
<rdar://problem/17943023> QoI: compiler displays wrong error when a float is provided to a Int16 parameter in init method
<rdar://problem/17951148> Improve error messages for expressions inside if statements by pre-evaluating outside the 'if'
<rdar://problem/18057815> Unhelpful Swift error message
<rdar://problem/18077468> Incorrect argument label for insertSubview(...)
<rdar://problem/18079213> 'T1' is not identical to 'T2' lacks directionality
<rdar://problem/18086470> Confusing Swift error message: error: 'T' is not convertible to 'MirrorDisposition'
<rdar://problem/18098995> QoI: Unhelpful compiler error when leaving off an & on an inout parameter
<rdar://problem/18104379> Terrible error message
<rdar://problem/18121897> unexpected low-level error on assignment to immutable value through array writeback
<rdar://problem/18123596> unexpected error on self. capture inside class method
<rdar://problem/18152074> QoI: Improve diagnostic for type mismatch in dictionary subscripting
<rdar://problem/18242160> There could be a better error message when using [] instead of [:]
<rdar://problem/18242812> 6A1021a : Type variable leaked
<rdar://problem/18331819> Unclear error message when trying to set an element of an array constant (Swift)
<rdar://problem/18414834> Bad diagnostics example
<rdar://problem/18422468> Calculation of constant value yields unexplainable error
<rdar://problem/18427217> Misleading error message makes debugging difficult
<rdar://problem/18439742> Misleading error: "cannot invoke" mentions completely unrelated types as arguments
<rdar://problem/18535804> Wrong compiler error from swift compiler
<rdar://problem/18567914> Xcode 6.1. GM, Swift, assignment from Int64 to NSNumber. Warning shown as problem with UInt8
<rdar://problem/18784027> Negating Int? Yields Float
<rdar://problem/17691565> attempt to modify a 'let' variable with ++ results in typecheck error about @lvalue Float
<rdar://problem/17164001> "++" on let value could give a better error message
Swift SVN r23782
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
Add all compiler crash tests to the validation-test/compiler_crashers
subdirectory. Add a RUN: line to each test case according to the current
behavior of the Swift compiler.
Swift SVN r23418
for binary non-logical operators in _The Swift Programming Language_ "Basic Operators."
Until rdar://18695154 is fixed, + and - are disabled; this leaves 1440 tests.
Approved by Dmitri.
Swift SVN r23096
Another thread could pull enqueued records into the cache while we're waiting on the lock, leaving us with an empty queue but an updated cache. Recognize this by sticking a generation on the cache and retrying instead of failing if the generation increased while we waited. Fixes rdar://problem/18856858.
Swift SVN r23091
It's not really XFAILed because it's a crash.
Disabling tests is a dangerous game, but this should be very temporary.
A better long term fix is to allow performance tests to run even when
some validation tests fail.
Swift SVN r23088
The archetype builder is responsible for figuring out what should go
into a generic signature anyway, so move the generic signature
creation there. This will also allow us to eliminate some code
duplication across Sema and AST.
Fixes compiler crasher 033.
Swift SVN r23030
This commit decouples StdlibUnittest from many details of
[Contiguous]Array, so tests can give useful feedback even in the
presence of a broken [Contiguous]Array implementation while we refactor.
Unfortunately, it wasn't practical to make _UnitTestArray use a
storage class other than _ContiguousArrayStorage[Base], so we still have
to watch out when making changes there.
Swift SVN r22875
ContiguousArray is a simpler component, thus less prone to breakage.
Builting the unit testing framework atop broken components is a very bad
idea, so let's not.
This is a reinstatement of an earlier commit, plus changes to make the
validation tests work.
Swift SVN r22867
Now that it disables access control, this lit definition applies to many
more tests, where we used to use %target-run-stdlib-swift before access
control came online.
Also, drop -Xfrontend -disable-access-control from a bunch of tests that
don't need it.
Swift SVN r22634
The name was not only long and unwieldy, but inconsistent with our
conscious decision to avoid the use of "elements" in APIs as mostly
redundant.
Swift SVN r22408
The previous version of this test was disallowing some thread
interleavings that I did not consider. See comments in the test for
more details.
Swift SVN r22300
This change includes a number of simplifications that allow us to
eliminate the type checker hack that specifically tries
AssertString. Doing so provides a 25% speedup in the
test/stdlib/ArrayNew.swift test (which is type-checker bound).
The specific simplifications here:
- User-level
assert/precondition/preconditionalFailure/assertionFailer/fatalError
always take an autoclosure producing a String, eliminating the need
for the StaticString/AssertString dance.
- Standard-library internal _precondition/_sanityCheck/etc. always
take a StaticString. When we want to improve the diagnostics in the
standard library, we can provide a separate overload or
differently-named function.
- Remove AssertString, AssertStringType, StaticStringType, which are
no longer used or needed
- Remove the AssertString hack from the compiler
- Remove the "BooleanType" overloads of these functions, because
their usefuless left when we stopped making optional types conform
to BooleanType (sorry, should have been a separate patch).
Swift SVN r22139
Fixes crasher #003 (rdar://problem/18232605). This time, also increase the buffer size for the necessary bindings so we don't clobber memory.
Swift SVN r22118
(If any other associated type member has a dependency on the invalid one, we won't be able to substitute and the compiler will crash.)
This addresses crash suite scenario 035. (rdar://problem/18233020)
Swift SVN r22116
You'll notice that we already had tests that made it appear that such declarations could work,
but they were only avoiding crashes because downstream errors were already marking the
enclosing functions as invalid. (If the errors were fixed, they would also crash the compiler.)
This addresses crash suite scenario 018. (rdar://problem/18299547)
Swift SVN r22109
There's no real use for declaring a property or global variable without binding it to anything, and closure context mangling relies on having a name to associate with closures. Fixes crash suite #006 (rdar://problem/18232699).
Swift SVN r22105
Doing so prevents another common source of stack overflows in the validator, and addresses crash suite scenarios 002 and 004.
(rdar://problem/18232499, rdar://problem/18232668)
Swift SVN r22104
This can only occur when validating mutually recursive existentials in type reference expressions, so it's "safe" to avoid validating member value decls in this case. There are still potential holes in our mechanism for checking for unsupported existentials, but at least this will eliminate another common crasher. (Crash suite scenario 010.)
Swift SVN r22035
