Once we've bound a type variable, we find those inactive constraints
that mention the type variable and make them active, so they'll be
simplified again. However, we weren't finding *all* constraints that
could be affected---in particular, we weren't searching everything
related to the type variables in the equivalence class, which meant
that some constraints would not get visited... and we would to
type-check simply because we didn't look at a constraint again when we
should have.
Fixes rdar://problem/29633747.
When trying to diagnose ambigiuty with constraint system check if any of the
unresolved type variables are related to generic parameters, and if so
try to diagnose a problem based on the number of constraints associated with
each of the unresolved generic parameters.
Number of constraints related to a particular generic parameter
is significant indicator of the problem, because if there are
no constraints associated with it, that means it can't ever be resolved,
such helps to diagnose situations like: struct S<A, B> { init(_ a: A) {}}
because type B would have no constraints associated with it.
When performing the occurs check, look for the *representative* of the
type variable we're about to bind, rather than the type variable
itself. Fixes rdar://problem/26845038, SR-1512, SR-1902, SR2635,
SR-2852, and SR-2766.
Slava pointed out that we have an existing version of the code from
the previous commit that's only used when checking types. Replace it
with the new code, which handles more cases.
For example, if someone tries to use the newly-generic type Cache,
from Foundation:
var cache = Cache()
they'll now get a fix-it to substitute the default generic parameters:
var cache = Cache<AnyObject, AnyObject>()
The rules for choosing this placeholder type are based on constraints
and won't be right 100% of the time, but they should be reasonable.
(In particular, constraints on associated types are ignored.)
In cases where there's no one concrete type that will work, an Xcode-
style placeholder is inserted instead.
- An unconstrained generic parameter defaults to 'Any'.
- A superclass-constrained parameter defaults to that class,
e.g. 'UIView'.
- A parameter constrained to a single @objc protocol (or to AnyObject)
defaults to that protocol, e.g. 'NSCoding'.
- Anything else gets a placeholder using the generic parameter's name
and protocol composition syntax.
rdar://problem/27087345
This flips the switch to have @noescape be the default semantics for
function types in argument positions, for everything except property
setters. Property setters are naturally escaping, so they keep their
escaping-by-default behavior.
Adds contentual printing, and updates the test cases.
There is some further (non-source-breaking) work to be done for
SE-0103:
- We need the withoutActuallyEscaping function
- Improve diagnostics and QoI to at least @noescape's standards
- Deprecate / drop @noescape, right now we allow it
- Update internal code completion printing to be contextual
- Add more tests to explore tricky corner cases
- Small regressions in fixits in attr/attr_availability.swift
For associated types inferred to be Any, we were allowing the type to
satisfy more specific same-type constraints, e.g. Element ==
Character (where Element is the associated type). This is clearly wrong.
The fix here is very specific to empty protocol compositions, and
removes some code in matchTypes() that doesn't make a lot of
sense. Looking back at the history, this was added in a commit that made
a handful of other changes, and it's not clear this particular change
was important for the issues that commit claimed to fix (and in fact
removing this regresses no tests).
Fixes rdar://problem/27515965.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
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 '>'.
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
a match, since it *could* be, and typically conforms to whatever the expression is.
Fixing this improves the diagnostic in Constraints/closures.swift significantly, and
fixes these bugs:
<rdar://problem/21718970> QoI: [uninferred generic param] cannot invoke 'foo' with an argument list of type '(Int)'
<rdar://problem/21718955> Swift useless error: cannot invoke 'foo' with no arguments
where before we produced:
error: cannot invoke 'foo' with an argument list of type '(Int)'
and now produce:
x.swift:5:10: error: generic parameter 'A' could not be inferred
Whatever.foo(a: 23)
^
x.swift:1:7: note: 'A' declared as parameter to type 'Whatever'
class Whatever<A: IntegerArithmetic, B: IntegerArithmetic> {
^
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.
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!
information about where the archetype was defined. Before:
t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int = A.foo()
^
After:
t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int = A.foo()
^
t.swift:2:8: note: 'T' declared as parameter to type 'A'
struct A<T> {
^
When a contextual conversion has a matching type, don't diagnose it as a
conversion error, the problem is due to something else (in this case, an
unresolved archetype somewhere else in the expression).
Before:
t.swift:6:17: error: cannot convert value of type 'Int' to specified type 'Int'
After:
t.swift:6:17: error: generic parameter 'T' could not be inferred
This should still be a bit better to provide information about where the T
archetype came from, but at least now it isn't completely wrong diagnostic.
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
Rearrange diagnoseGeneralConversionFailure to diagnose structural problems
even if we have some UnresolvedTypes floating around, then reject constraint
failures with UnresolvedTypes in them even harder. This keeps us giving
good errors about failures where we have a structural problem (with buried
irrelevant details) while not complaining about cases that are actually
ambiguous.
The end result of this is that we produce a lot better error messages in the
case of failed archetype inference. This also highlights the poor job we do
handling multi-stmt closureexprs...
This makes diagnoseGeneralConversionFailure more conservative: it
now never diagnoses a failed conversion when it involves a type that
has unresolved type in it. These types could not be resolved, so it
is better to let ambiguity resolution handle the problem.
On "[] as Set", we would previously get:
error: 'Set<_>' is not convertible to 'Set<Element>'
now we get:
error: generic parameter 'Element' could not be inferred
An optimization should be added in order for the new one to be
efficient, i.e. if the `count` value is equal to `1`, the underlying
`Builtin.destroy` should be called, instead of
`Builtin.destroyArray`.
