Commit Graph

11 Commits

Author SHA1 Message Date
Daniel Duan
780b58a9a5 [Parser] update tests for 'inout' syntax adjustment 2016-02-26 01:33:22 -08:00
Chris Lattner
4b8ccacf63 Fix <rdar://problem/22243469> QoI: Poor error message with throws, default arguments, & overloads
and probably others.

When we're type-checking a failed ApplyExpr that has an overload set that
prevents getting a specific type to feed into the initial typechecking of
the argument list, ranking can often narrow down the list of candidates
further, to the point where there is only one candidate left or where all
candidates agree that one argument is wrong.

In this case, re-type-check the subexpr with the expected type.  In the case of
rdar://problem/22243469 we now produce:

t.swift:6:11: error: invalid conversion from throwing function of type '() throws -> ()' to non-throwing function type '() -> Void'
  process {
          ^

instead of:

t.swift:6:3: error: cannot invoke 'process' with an argument list of type '(() throws -> ())'
  process {
  ^
t.swift:6:3: note: overloads for 'process' exist with these partially matching parameter lists: (UInt, fn: () -> Void)
  process {
  ^

Which is a heck of a lot less specific.  Similarly, in the testcase from rdar://23550816, instead
of producing:

  takeTwoFuncsWithDefaults { $0 + 1 }
error: cannot invoke 'takeTwoFuncsWithDefaults' with an argument list of type '((Int -> Int)?)'
note: expected an argument list of type '(f1: (Int -> Int)?, f2: (String -> String)?)'

we now produce:
error: cannot convert value of type '_ -> Int' to expected argument type '(String -> String)?'

which is a lot closer to what we want to complain about.
2015-11-17 20:27:47 -08:00
Chris Lattner
85501b436e Remove some weird hacks that added special case behavior for operators. This
code had the effect of squishing the note that printed the overload candidate
set for the operators in question.  While these are not generally helpful given
how many overloads we have of (e.g.) the + operator, it doesn't do us any good
to have special cases like this, because methods can have tons of overloads as
well.
2015-11-15 21:24:57 -08:00
Chris Lattner
622ea5e2f6 wind down most of CSDiag's uses of getUserFriendlyTypeName to pass the Type
directly into the diagnostics subsystem.  This ensures a more consistent 
treatment of type printing (e.g. catches a case where a diagnostic didn't 
single quote the type) and gives these diagnostics access to "aka".


Swift SVN r30609
2015-07-25 00:54:05 +00:00
Chris Lattner
63f99a486c Move CallExpr diagnostics over to the same overload candidate diagnosis
facilities used by operators etc.  This required a bunch of changes to make
the diagnostics changes strictly an improvement:

  - Teach the new path about calls to TypeExprs.
  - Teach evaluateCloseness some simple things about varargs.
  - Make the generic diagnosis logic produce a better error when there is 
    exactly one match.

Overall, the resultant diagnostics are a step forward: we now produce candidate
set notes more uniformly, and the messages about some existing ones are 
more specific.  This is just another stepping stone towards progress though.



Swift SVN r30057
2015-07-10 04:26:42 +00:00
Dmitri Hrybenko
2d12d510f2 Lowercase the first character in compiler diagnostics for consistency
Swift SVN r24634
2015-01-22 06:19:14 +00:00
Joe Pamer
f935a15460 Fix a typo in our bin application diagnostic. (rdar://problem/19422548)
Swift SVN r24613
2015-01-21 22:11:50 +00:00
Dmitri Hrybenko
3b04d1b013 tests: reorganize tests so that they actually use the target platform
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK.  The driver was defaulting to the
host OS.  Thus, we could not run the tests when the standard library was
not built for OS X.

Swift SVN r24504
2015-01-19 06:52:49 +00:00
Joe Pamer
dc338c2a71 Update wording of some new diagnostics.
Swift SVN r23783
2014-12-08 21:56:52 +00:00
Joe Pamer
2912159776 Improve diagnostics for expression typecheck errors
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
2014-12-08 21:56:47 +00:00
Jordan Rose
e83c117c30 [test] Hack: run stdlib tests first to start long-running tests earlier.
This decreases total testing time by over a minute on my old Mac Pro.
It probably has much less effect on systems with fewer cores, but shouldn't
be any worse there.

Swift SVN r22745
2014-10-15 01:30:51 +00:00