Don't assert that generic arg lists have the same lengths. We don't
currently allow nested generics, but we try to type-check anyway, and
one of the effects is sticking the generic params for both the outer and
inner classes on the inner type. Instead, just error out.
<rdar://problem/21967211>
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
fixit hint in CSDiags instead of being a FixKind. This resolves a number of issues with
it, particularly that it didn't actually check to see if the function in question takes
a () argument or not.
This fixes:
<rdar://problem/21692808> QoI: Incorrect 'add ()' fixit with trailing closure
among other issues.
Swift SVN r31728
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
This allows us to remove the workaround generic overloads for "print" without sacrificing good diagnostics for its unavailable overloads. (rdar://problem/21499048, rdar://problem/21582758, rdar://problem/22126141)
Swift SVN r31169
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31105
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
Fix construction and simplication of constructor member locators, so
that locators involving constructor members can be simplified during
diagnosis.
<rdar://problem/21427130> Swift can't discriminate on arity of function parameters
Swift SVN r30932
This came up with SourceKit fuzz testing on the stdlib. I don't have a
reduced testcase right now.
Progress on <rdar://problem/19554069>.
Swift SVN r30882
- 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
constraint failed, leaving a bunch of other solvable constraints laying
around in the system as inactive.
This is a problem for diagnostics emission, because it turns around and
reaches into the constraint system for some inactive constraint, assuming
that anything left could not be solved. The constraint system attempted to
solve this by taking the first failure and putting it into the failedConstraint
with the intention of driving diagnostics, but just because it happened to fail
first in constraint-solver-worklist-order doesn't mean it is the most pertinent
one to diagnose.
Swift SVN r30787
"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
Some types are born to mutating methods, and some types have mutating methods thrust upon them. Protocol extensions put classes into the latter category. A 'mutating' protocol extension method requires a mutable 'self' base even when applied to a class. Fix the synthesized getter for lazy properties so that it's only marked 'mutating' on value types, since otherwise it'd now be impossible to access lazy properties on immutable class references.
Fixes part of rdar://problem/21578832, allowing 'mutating' methods from protocol extensions to apply to mutable class references. Properties with mutating setters are still improperly allowed on immutable class reference bases though.
Swift SVN r30557
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
If a function declaration possessed default parameters, and was invoked with a single argument expression that was modeled as a type variable, the compiler would often crash during type application. This was due to the fact that during simplification, we would bind the type variable to the full tuple type of the parameter list. Later on, during constraint application, we would then look to whatever expression created the type variable for information on its default arguments - even if no such thing was possible. (E.g., we would examine, say, an IfExpr expecting to find information on its default arguments.) In these cases, we should have instead been binding the argument type variable to the first element of the parameter tuple.
Swift SVN r30486
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
