This case attempts to diagnose assignment into an invalid lvalue which only had
a computable type due to a fixit that the constraint solver was assuming. In this
situation, don't diagnose the invalid lvalue at all, diagnose the required fix.
Introduce a new constraint kind, BindParam, which relates the type of a
function parameter to the type of a reference to it from within the
function body. If the param type is an inout type, the ref type is an
lvalue type with the same underlying object type; otherwise the two
types must be the same. This prevents DeclRefExprs from being inferred
to have inout type in some cases.
<rdar://problem/15998821> Fail to infer types for closure that takes an inout argument
Swift SVN r32183
of providing contextual diagnostics (e.g. producing the warning in
Constraints/dynamic_lookup.swift). This drops a specific diagnostic about
force casting the result of as! which was added in the Swift 1.2 timeframe
to explain the change in cast semantics. Now that as! has been around for
a long time, it is more confusing than helpful.
Swift SVN r31887
- 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
change its implementation to take a list of TupleTypeElt for both the
from/to tuple type, but provider a convenience wrapper that takes the
from/to tuple type as TupleType's.
Swift SVN r31733
expr diagnosis stuff, giving us much better diagnostics on the cases in
expr/closure/closures.swift. This is part #2 of resolving
<rdar://problem/22333281> QoI: improve diagnostic when contextual type of closure disagrees with arguments
Swift SVN r31717
argument list mismatches, and diagnose them with a very specific error when
they occur in member lookups. This fixes
<rdar://problem/22356434> QoI: Missing diagnostic for invalid arguments passed to enum case constructor
where before we'd produce:
ee.swift:5:16: error: type of expression is ambiguous without more context
let list: E = .C(wrongLabel: 0)
~^~~~~~~~~~~~~~~~
now we produce:
ee.swift:1:17: error: incorrect argument label in call (have 'wrongLabel:', expected 'label:')
let list: E = .C(wrongLabel: 0)
^~~~~~~~~~~
label
I think that unresolved member exprs now get good diagnostics in all cases that they have
a contextual type, but of course there are lots more cases where we're not getting a
contextual type.
Swift SVN r31402
ConstraintSystem::applySolution into its own helper function to reduce
indentation and make ConstraintSystem::applySolution much more simple
and obvious. NFC.
Swift SVN r31290
constraints of each kind, enhance FailureDiagnosis::diagnoseGeneralConversionFailure to
ignore conversion constraints that are either trivially resolvable (like Int conforming
to IntegerLiteralConvertible) or constraints that cannot be resolved because a type
variable is ambiguous.
This eliminates the last (known to me at least!) source of diagnostics that end up
complaining about obviously incorrect issues.
Swift SVN r31065
and use it in the diagnostics path (only!) to revisit active constraints that
are left in the system after a failure is found. This improves a number of
otherwise sad diagnostics in the testsuite and resolves rdar://22083115.
The one QoI regression (in throwing_functions.swift) is now tracked by 22158167.
Swift SVN r31027
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
machinery, instead of in multiple places in CSSolver and CSDiags. This leads
to more predictable behavior (e.g. by removing the UnboundGenericParameter
failure kind) and eliminates a class of "'_' is not convertible to 'FooType'"
diagnostics.
Swift SVN r30923
- Produce more specific diagnostics relating to different kinds of invalid
- add a testcase, nfc
- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of
Not including r30787 means that we still generate bogus diagnostics like:
[1, 2, 3].doesntExist(0) // expected-error {{type 'Int2048' does not conform to protocol 'IntegerLiteralConvertible'}}
But it is an existing and separable problem from the issues addressed here.
Swift SVN r30819
r30787 causes our tests to time out; the other commits depend on r30787.
Revert "revert part of my previous patch."
Revert "Produce more specific diagnostics relating to different kinds of invalid"
Revert "add a testcase, nfc"
Revert "- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of"
Revert "Fix places in the constraint solver where it would give up once a single "
Swift SVN r30805
performMemberLookup, eliminating a ton of duplicated logic, but keeping the
same general behavior.
- Now that r30787 landed, we can have diagnoseGeneralMemberFailure inform
clients when a member lookup fails due to referencing a candidate decl of
ErrorType (i.e, it is already invalid somehow). When this happens, there is
no reason to diagnose a problem, because the original issue has been diagnosed
and anything we produce now is just garbage.
The second point cleans up a bunch of bogus diagnostics in the testsuite, which are
*actually* due to upstream error that are already diagnosed.
Swift SVN r30789
"unavoidable failure" path, along with Failure::DoesNotHaveNonMutatingMember and
just doing some basic disambiguation in CSDiags.
This provides some benefits:
- Allows us to plug in much more specific diagnostics for the existing "only has
mutating members" diagnostic, including producing notes for why the base expr
isn't mutable (see e.g. test/Sema/immutability.swift diffs).
- Corrects issues where we'd drop full decl name info for selector references.
- Wordsmiths diagnostics to not complain about "values of type Foo.Type" instead
complaining about "type Foo"
- Where before we would diagnose all failures with "has no member named", we now
distinguish between when there is no member, and when you can't use it. When you
can't use it, you get a vauge "cannot use it" diagnostic, but...
- This provides an infrastructure for diagnosing other kinds of problems (e.g.
trying to use a private member or a static member from an instance).
- Improves a number of cases where failed type member constraints would produce uglier
diagnostics than a different constraint failure would.
- Resolves a number of rdars, e.g. (and probably others):
<rdar://problem/20294245> QoI: Error message mentions value rather than key for subscript
Swift SVN r30715
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue
While I'm in the area, remove some dead code.
Swift SVN r30713
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
typeCheckExpression takes a convertType and a contextualType, but the only
client of contextualType is pattern binding initialization that wants to
provide a hint to the initializer, but the type may not be fully formed
(e.g. just Array instead of Array<Int>) so it can't provide a full
convertType to that type.
After trying various ways of eliminating the concept and failing, repaint it
instead: instead of typeCheckExpression taking *both* a convertType and a
contextualType (even though they are mutually exclusive), have it only take
a single convertType and add a bit to TypeCheckExprOptions to indicate whether
it is a hint or a strong conversion. This simplifies all the callers of
typeCheckExpression and makes further evolution simpler.
Swift SVN r30658
setConversionType along with the constraints they install. The constraints
should be enough by themselves, and CSDiags shouldn't need them to
bias the solution.
Of course, the constraints weren't enough, so improve CSDiags so that it can
do the right thing without them.
Swift SVN r30636
Requiring a variadic parameter to come at the end of the parameter
list is an old restriction that makes no sense nowadays, and which we
had all thought we had already lifted. It made variadic parameters
unusable with trailing closures or defaulted arguments, and made our
new print() design unimplementable.
Remove this restriction, replacing it with a less onerous and slightly
less silly restriction that we not have more than one variadic
parameter in a given parameter clause. Fixes rdar://problem/20127197.
Swift SVN r30542
with no returns *must* be (), add a defaulting constraint
so that it will be inferred as () in the absence of
other possibilities.
The chief benefit here is that it allows better QoI when
the user simply hasn't yet written the return statement.
Doing this does regress a corner case where an attempt
to recover from an uncalled function leads to the
type-checker inferring a result for a closure that
doesn't make any sense at all.
Swift SVN r30476
which allows solving of a constraint system to succeed without emitting
errors in the face of ambiguous solutions. This is important for CSDiag
because it is in the business of trying to solve subexpressions of a global
expression - and it wants to know the difference between a subexpression
that is inherently impossible to solve, vs one that is simply ambiguous
because its context has been removed.
Use this in CSDiag's typeCheckChildIndependently() to provide it an
extra flag that enables this behavior. This is currently unused, so NFC
with this patch.
Swift SVN r30402
It looks like we were checking in the wrong place, as a result we didn't
catch stuff like
class G<T : AnyObject> {}
_ = G<P>()
This would crash later in IRGen.
Make the conformsToProtocol() check do the right thing, and remove some
other miscellaneous diagnostics in the process. Also, make the
"type 'T' does not conform to protocol 'P'" diagnostic a bit more
detailed.
Unfortunately in a few instances we lose a more descriptive diagnostic to
a general 'cannot invoke 'foo' with argument list of type 'T'' error. The
argument matching diagnostics need to be addressed anyway though.
Fixes <rdar://problem/20311619>.
Swift SVN r29737
