With a TypeLoc, we have a chance to offer diagnostics or even fix-its
to the contextual type, even though it's not represented by an
expression in the constraint system. This commit mostly just passes it
through, without attempting to use it anywhere or even pass a real
TypeLoc (with a valid TypeRepr).
(It does drop the contextual type parameter from
typeCheckExpressionShallow, since there were zero callers using it.)
No functionality change...yet.
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.
make sure that properties and subscripts have a self type in their tracked
type. This makes SubscriptExpr processing more logical (given that it applies
both self and an index list), by putting hacks in more principled places.
It would be great to someday eliminate SubscriptExpr entirely, but this isn't
going to happen in the short term. NFC.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
(like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.
I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)
The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
Type level lookups can fail because the lookup is on an existential
metatype, like `MyProtocol.staticMethod(_:)` is invalid; however the
error message is unclear: “static member 'staticMethod(_:)' cannot be
used on instance of type ‘MyProtocol.Protocol’”.
This fix checks the base of member lookups that failed with the reason
UR_TypeMemberOnInstance for being existential metatypes. It produces
the clearer message “static member ‘staticMethod(_:)’ cannot be used on
protocol metatype ‘MyProtocol.Protocol’”. This change makes it clear
that the use of a static member on the *existential* metatype is the
problem.
- Fix ExprTypeSaverAndEraser to save & restore the invalid bit on closure parameter decls.
- Teach CalleeCandidateInfo::evaluateCloseness to not try to find generic subs on types that
contain a unresolved type within them.
With these changes, the compiler doesn't segfault on the testcase when assertions are
enabled. It still doesn't produce a great diagnostic though.
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
correct location for generic parameters that cannot be inferred. The cases that
I thought were incorrectly rejected on first glance were actually correct.
With this change the base expression of the subscript (beeing already
revalidated earlier in the function) is passed to diagnoseUnviableLookupResults
to emit a fitting diagnostic.
In member ref expressions, if the base is optional, and the expected
expression result is either optional or unknown, suggest a fixit that
makes it into an optional chain expr rather than force unwrapping.
Since in many cases the actual fixit is emitted during diagnosis, and
thus, while type checking sub exprs with no contextual type specified
(so nothing to check for preferring optionality), we also need an
additional flag to pass down from FailureDiagnosis for whether we
prefer to fix as force unwrapping or optional chaining.
I attempted to do this same job via providing a convert type but
setting the ConvertTypeIsOnlyAHint flag on the type checker, but
unfortunately there are a lot of other moving parts that look at that
type, even if it is only supposed to be a hint, so an additional flag
to the CS ended up being cleaner.
Previously we would produce:
t.swift:3:3: error: binary operator '+=' cannot be applied to operands of type 'Int' and '_'
a += a + b
~ ^ ~~~~~
with a candidate set to follow. Now we properly match up the inout/lvalue type and produce
the following more specific diagnostic:
t.swift:3:10: error: cannot convert value of type 'UInt32' to expected argument type 'Int'
a += a + b
^
pointing the the "b".
Straightforward extension of the previous work here to handle callees
with multiple generic parameters. Same type requirements are already
handled by the ArchetypeBuilder, and protocol conformance is handled
explicitly. This is still bailing on nested archetypes.
Pre-existing tests updated that now give better diagnoses.
Previously, type checking arguments worked fine if the entire arg was
UnresolvedType, but if the type just contained UnresolvedType, the
constraint system always failed via explicitly constraining to
unresolved.
Now in TypeCheckConstraints, if the solution allows for free variables
that are UnresolvedType, then also convert any incoming UnresolvedTypes
into variables. At worst, in the solution these just get converted back
into the same Unresolved that they started with.
This change allows for incorrect tuple/function type possibilities to
make it back out to CSDiag, where they can be more precisely diagnosed
with callee info. The rest of the changes are to correctly figure
out the failure info when evaluating more types of Types.
New diagnosis for a partial part of an arg type not confroming. Tests
added for that. Expected errors changed in several places where we
now get real types in the diagnosis instead of '(_)' unresolved.
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.
This is a quick follow-up to
<https://github.com/apple/swift/pull/1160>, to replace the becoming
deprecated getArchetype() with doing the same thing via calling through
to ArchetypeBuilder with a declContext.
Uses findGenericSubstitutions() to do so. So this site could take
advantage of destructuring of more complex params containing generics.
Right now, though, that never happens. For complex params the
(unfortunately, worse) diagnosis happens in diagnoseFailureForExpr() on
the argument expression before reaching here. I’d like to improve that
in future work.
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.
When we have a contextual type of Optional<SomeNominal>, we get overload
lookup results indicating that the found member needs to look through the
optional. Do so!
Not all types are l-valuable, notably InoutType's. This seems like a
weird restriction to put in the type checker, but it is the cleanest
solution to this. The better solution would be to change how
inoutexpr/inouttype are represented completely... maybe someday.
In both figuring out candidate closeness and in diagnosing generic
parameter errors, if the parameter is a GenericTypeParamType, get its
decl’s archetype to perform archetype substitutability checking upon.
If the mismatched argument is on an archetype param, check to see
whether the argument conforms to all of the protocols on the archetype,
using a specific does-not-conform diagnosis if one or more protocols
fail.
Also added another closeness class
`CC_GenericNonsubstitutableMismatch`, which happens when more than one
argument is a mismatch, but all the failing arguments are of the same
type and mismatch only because of substitutability. This closeness is
farther away than normal `CC_ArgumentMismatch` so that if we note
expected matches, we’ll prefer non-generic matches. But if this is the
result, we can still produce the specific conforms-to-protocol
diagnosis (since, in a sense, it’s only one type of argument that is
wrong even though it is multiple arguments).
When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
- Improve the specific cases of nil and empty collection literals.
- Improve cases of contextual member lookup where the result type of the looked up member disagrees with context.
- Add some fixme's to the testsuite for cases of this diagnostic that should be diagnosed in other ways.
This standardizes processing of callees in invalid applyexprs, eliminating
bogus diagnostics like:
t.swift:6:2: error: cannot invoke closure of type '() -> _' with an argument list of type '()'
we now properly diagnose the example in closure/closures.swift as ambiguous,
but don't do a particularly good job of saying why. That is to follow.
There are two problems here, first we were diagnosing type member
constraints with the "function 'foo' was used as a property" error,
which doesn't make sense.
Second, we were diagnosing member constraints as lookup failures when
the constraint was actually referring to an archetype in its anchor
expression that wasn't resolved. Address this by simply ignoring the
constraint and letting ambiguity resolution handle it.
Before:
t.swift:5:9: error: function 'foo' was used as a property; add () to call it
After:
t.swift:5:9: error: generic parameter 'T' could not be inferred
let a = foo()
t.swift:4:6: note: in call to function 'foo'
func foo<T: IntegerType>() -> T.Type { return T.self }
Thanks to Jordan for noticing this!
