Currently absence of `subtyping` is the only problem detected and diagnosed specifically
for `inout` parameters, but there could be type mismatches in `inout` positions as well
and we can use `argument-to-parameter mismatch fix to detect and diagnose them.
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
- Attempting to construct class object using metatype value via
non-required initializer
- Referencing initializer of protocol metatype base
Both of the diagnostics are used by `AllowInvalidInitRef` fix.
When the compiler fails to find an overload with suitable parameter or return types, it often attaches a note listing the available overloads so that users can find the one they meant to use. The overloads are currently ordered in a way that depends on the order they were declared, so swift-evolve would sometimes cause tests involving these diagnostics to fail.
This change emits the list in a textually-sorted order instead. The names were already being sorted as they were inserted into a std::set, so this shouldn’t significantly slow down the diagnostic.
This builds on initial commit which added `RelabelArguments` fix
to the solver that only supported `missingLabels` at that moment,
but now it supports all three posibilities - missing/extraneous and
incorrect labels.
For `use(self.init())`, target of RebindSelfInConstructorExpr should be
call expression instead of paren expression.
rdar://problem/41416911
Possibly: rdar://problem/41593987
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
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.
The issue here is that the constraint solver was deciding on
FixKind::RelabelCallTuple as the fix for the problem and emitting the
diagnostic, even though there were two different fixes possible.
CSDiags has the infrastructure to support doing doing the right thing
here, but is only being used for ApplyExprs, not SubscriptExprs.
The solution is to fix both problems: remove FixKind::RelabelCallTuple,
to let CSDiags handle the problem, and enhance CSDiags to treat
SubscriptExpr more commonly with ApplyExpr. This improves several cases
where the solver was picking one solution randomly and suggesting that
as a fix, instead of listing that there are multiple different solutions.
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.
- Enhance the branch new argument label overload diagnostic to just
print the argument labels that are the problem, instead of printing
the types inferred at the argument context. This can lead to confusion
particularly when an argument label is missing. For example before:
error: argument labels '(Int)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
after:
error: argument labels '(_:)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
Second, fix <rdar://problem/22451001> QoI: incorrect diagnostic when argument to print has the wrong type
by specifically diagnosing the problem when you pass in an argument to a nullary function. Before:
error: cannot convert value of type 'Int' to expected argument type '()'
after:
error: argument passed to call that takes no arguments
print(r22451001(5))
^
Swift SVN r31795
And give a proper warning when you use 'try?' in a non-failable init.
And do the right thing when trying to SILGen 'try?' delegating to a
failable throwing init.
And make sure DI understands that this is, in fact, an initialization.
More rdar://problem/21692467
Swift SVN r31060
which we have a contextual type that was the failure reason. These are a bit
longer but also more explicit than the previous diagnostics.
Swift SVN r30669
conversion failures, making a bunch of diagnostics more specific and useful.
UnavoidableFailures can be very helpful, but they can also be the first constraint
failure that the system happened to come across... which is not always the most
meaningful one. CSDiag's expr processing machinery has a generally better way of
narrowing down which ones make the most sense.
Swift SVN r30647
RebindSelfInConstructorExpr, which gets issues related to
self.init and super.init onto the CallExpr best path, instead
of in the generic overload constraint failure morass.
Swift SVN r30067
argument list for a CallExpr instead of matching a gang of typevartypes against them.
This allows us to produce better matches in some cases.
Swift SVN r30065
