This reverts commit dc24c2bd34.
Turns out Chris fixed the build but when I was looking at the bots, his fix had
not been tested yet, so I thought the tree was still red and was trying to
revert to green.
* [Fixit] Add a fixit for converting non-trailing closures to trailing closures.
* [test] Update test to reflect the added note about converting to trailing closures.
Per the discussion in SR-1612, we don’t have a robust mechanism for
checking this and should warn about it.
Signed-off-by: Robert Widmann <devteam.codafi@gmail.com>
along with recent policy changes:
- For expression types that are not specifically handled, make sure to
produce a general "unused value" warning, catching a bunch of unused
values in the testsuite.
- For unused operator results, diagnose them as uses of the operator
instead of "calls".
- For calls, mutter the type of the result for greater specificity.
- For initializers, mutter the type of the initialized value.
- Look through OpenExistentialExpr's so we can handle protocol member
references propertly.
- Look through several other expressions so we handle @discardableResult
better.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
This reverts commit 073f427942,
i.e. it reapplies 35ba809fd0 with a
test fix to expect an extra note in one place.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
wraps up SE-0004 and SE-0029.
I consider the diagnostic changes in Constraints/lvalues.swift to be
indicative of a QoI regression, but I'll deal with that separately.
set where all members of the set produce the same type, produce a more
specific error.
Before:
t.swift:4:17: error: no '&&' candidates produce the expected contextual result type 'Int'
return a == b && 1 == 2
^
t.swift:4:17: note: produces result of type 'Bool'
return a == b && 1 == 2
^
after:
t.swift:4:17: error: '&&' produces 'Bool', not the expected contextual result type 'Int'
return a == b && 1 == 2
^
This improves the situation reported in https://twitter.com/_jlfischer/status/712337382175952896
The 5000 byte treshold is too generous on 32-bit systems to trigger the expression too complex test. Reducing it to 4000 causes the compiler to bail (as expected) on these platforms while retaining the expected behavior on 64-bit systems.
Correctly determine callee closeness for func/ops that include generics
as part of more complicated parameters, i.e. tuple or closure args
containing generics as elements or args/results. Still only handling
single archetypes.
Also added code to check generic substitutions already made in the callee
parameters, which further helps diagnosis.
Producing single argument mismatches involving generics causes some
gross looking error messages if the generic mismatches get put into the
same closeness bucket as non-generic mismatches.
E.g. `var v71 = true + 1.0` used to produce `error: cannot convert
value of type 'Bool' to expected argument type 'Double’`, but would now
end up with `binary operator '+' cannot be applied to operands of type
'Bool' and 'Double’` `overloads for '+' exist with these partially
matching parameter lists: (Double, Double), (T, T.Stride), (T.Stride,
T)`.
Resolve this by adding CC_OneGenericArgumentNearMismatch and
CC_OneGenericArgumentMismatch, that are similar but ever so slightly
not as close as a mismatch involving non-generic functions. This gets
back the original error message in cases like the above, because there
is only one declaration of `+` which partially matches and is
non-generic, and the generic partial matches are now farther away.
But now single arg mismatches and nearness work for single-archetype
generic functions, as in the additions to the SR-69 test at the end of
deduction.swift.
In the specific case of sr-69, and in a bunch of other code where
errors arise involving generic function application, better type
constraint failure diagnoses are being masked by the overly
conservative implementation in evaluateCloseness(). If the actual arg
types didn’t exactly match the parameter types, we’d always diagnose a
non-specific arguments-don’t-match error instead of allowing discovery
of better errors from the constraint system.
This commit adds more cases where evaluateCloseness will return
CC_ExactMatch, specifically in application of functions with one or
more arguments of a single archetype, like `func min<T: Comparable>(T,
T) -> T`. It verifies that the actual argument type
isSubstitutableFor() the archetype, and that all such arguments are of
the same type. Anything more complicated than that still has the
previous behavior of not matching at all.
I think the final answer here ought to be to make a constraint system
with type variables for any archetypes, add appropriate constraints to
the actual args and then see if the system can solve all the argument
constraints at once. That’s because the next most complicated set of
things to handle in the stdlib are things like `func -<T:
Strideable>(lhs: T, rhs: T.Stride)` where generic argument types depend
on each other. I tried attacking that, but it was too big of a bite for
me to manage all at once. But there are FIXME’s here to try that again
at some point.
New tests for SR-69 are at the end of deduction.swift, and the rest of
the test changes are generally improved deduced diagnoses. I think the
changed diagnoses in materializable_restrictions.swift is the only one
which is worse instead of better, and that’s just because the previous
general message mentioned `inout` basically accidentally. Opportunity
for further improvement (a new diagnosis maybe) there.
Validation tests run and passed.
overloaded argument list mismatches. We printed them in simple cases
due to "Failure" detecting them in trivial situations. Instead of
doing that, let CSDiags do it, which allows us to pick things out of
overload sets and handle the more complex cases well.
This is a progression across the board except for a couple of cases
where we now produce "cannot convert value of type 'whatever' to
expected argument type '(arglist)'", this is a known issue that I'll
fix in a subsequent commit.
Previously we erroneously complained:
error: cannot invoke 'contains' with an argument list of type '(String)'
now we correctly complain:
error: unexpected non-void return value in void function
This enhances CSDiags to use "getTypeOfMember" when analyzing method
candidates that are applied to a known base type. Using it allows us to
substitute information about the base, resolving archetypes that exist in
subsequent argument positions. In the testcase, this means that we use
information about Set<String> to know that the argument to "contains" is a
String.
This allows us to generate much better diagnostics in some cases, and works
around some limitations in the existing stuff for handling unresolved
archetypes. One unfortunate change is the notes in Misc/misc_diagnostics.swift.
Because we don't track argument lists very well, we are flattening an argument
list that is actually ((Int,Int)) into (Int, Int) so we get a bogus looking
diagnostic. This was possible before this patch though, it is just one
more case that triggers the issue.
Now we perform the correct check: making sure that we have TBI on for
iOS7.0-Earlier and on for iOS8.0+Later.
The actual functionality that occurs is that we /always/ have TBI on when the
triple is an AArch64 target. Then the backend determines via the triple whether
it is supported or not for the specific os version.
I also removed the executable test bit requires since this test does not execute
anything, it just runs FileCheck tests.
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.
