Skip to content

[pull] swiftwasm-release/5.3 from release/5.3 #1283

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jun 23, 2020
Merged

Conversation

pull[bot]
Copy link

@pull pull bot commented Jun 22, 2020

See Commits and Changes for more details.


Created by pull[bot]. Want to support this open source service? Please star it : )

slavapestov and others added 6 commits June 21, 2020 23:45
…aints

Under certain circumstances, introducing a concrete same-type or
superclass constraint can re-introduce conformance constraints
which were previously redundant.

For example, consider this code, which we correctly support today:

protocol P {
  associatedtype T : Q
}

protocol Q {}

class SomeClass<U : Q> {}

struct Outer<T> where T : P {
  func inner<U>(_: U) where T == SomeClass<U>, U : Q {}
}

The constraint 'T == SomeClass<U>' makes the outer constraint
`T : P' redundant, because SomeClass already conforms to P.
It also introduces an implied same-type constraint 'U == T.T'.

However, whereas 'T : P' together with 'U == T.T' make 'U : Q'
redundant, the introduction of the constraint 'T == SomeClass<U>'
removes 'T : P', so we re-introduce an explicit constraint 'U : Q'
in order to get a valid generic signature.

This code path did the right thing for constraints derived via
concrete same-type constraints, but it did not handle superclass
constraints.

As a result, this case was broken:

struct Outer<T> where T : P {
  func inner<U>(_: U) where T : SomeClass<U>, U : Q {}
}

This is the same example as above, except T is related via a
superclass constraint to SomeClass<U>, instead of via a concrete
same-type constraint.

The subtlety here is that we must check if the superclass type
actually conforms to the requirement source's protocol, because it
is possible to have a superclass-constrained generic parameter
where some conformances are abstract. Eg, if SomeClass did not
conform to another protocol P2, we could write

func foo<T, U>(_: T, _: U) where T : SomeClass<U>, T : P2 {}

In this case, 'T : P2' is an abstract conformance on the type 'T'.

The common case where this would come up in real code is when you
have a class that conforms to a protocol with an associated type,
and one of the protocol requirements was fulfilled by a default in
a protocol extension, eg:

protocol P {
  associatedtype T : Q

  func foo()
}

extension P {
  func foo() {}
}

class ConformsWithDefault<T : Q> : P {}

The above used to crash; now it will type-check correctly.

Fixes <rdar://problem/44736411>, <https://bugs.swift.org/browse/SR-8814>..
Disallow holes to be inferred as supertype bindings  while inferring
bindings from other type variables (based on transitivity of subtype
conversions), otherwise it would be possible to record a hole without
recording associated fix.

Resolves: rdar://problem/64368545
(cherry picked from commit 2283208)
AST rewriter needs to make sure that all of the arguments are loaded
since it's currently possible to pass l-value type as an argument to
object literal (`#{file, color, image}Literal`).

Resolves: rdar://problem/62927467
(cherry picked from commit baaff0d)
…ete-with-superclass-5.3

GSB: Teach 'derived via concrete' computation about superclass constraints [5.3]
[5.3][CSApply] Always try to load arguments constructing object literals
[5.3][ConstraintSystem] Don't propagate holes through supertype inference
@pull pull bot merged commit d2e1ae0 into swiftwasm-release/5.3 Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants