Skip to content

Sema: Make type resolution for EnumElementPattern less eager #33227

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 2 commits into from
Aug 1, 2020

Conversation

AnthonyLatsis
Copy link
Collaborator

@AnthonyLatsis AnthonyLatsis commented Jul 31, 2020

Delay contextual type resolution for EnumElementPattern until coercePatternToType is called to further reduce the scope of UnboundGenericType, and use name lookup instead to resolve the pattern.

The definitive fix would be to move CaseStmt checking into the constraint system (AFAIK CaseStmt is the only remaining place where EnumElementPattern checking still relies on coercePatternToType).

@AnthonyLatsis AnthonyLatsis requested review from CodaFi, xedin and slavapestov and removed request for CodaFi July 31, 2020 12:54
@slavapestov
Copy link
Contributor

@swift-ci Please test source compatibility

@slavapestov
Copy link
Contributor

@swift-ci Please smoke test

@AnthonyLatsis AnthonyLatsis merged commit 337501e into swiftlang:master Aug 1, 2020
@AnthonyLatsis AnthonyLatsis deleted the unbound-thinout-1 branch August 1, 2020 13:14
@hamishknight
Copy link
Contributor

What about cases where the contextual type is needed to resolve the case? I believe this will no longer compile with this change:

enum E {
  case e
}

struct S<T> {}
extension S where T == E {
  func foo(_ x: Any) {
    switch x {
    case T.e:
      break
    default:
      break
    }
  }
}

As you say, it would be nice if we could move this into the constraint system such that we resolve patterns while generating constraints, which would allow us to keep the generic opening contained and allow the above example to remain valid.

@AnthonyLatsis
Copy link
Collaborator Author

Argh.. well noticed. @CodaFi Should we revert this? Not sure if I can figure out the proper constraint-system-oriented fix in reasonable time, considering the regression.

@hamishknight
Copy link
Contributor

Yeah IMO we should revert this if a fix for the above case isn't going to be landed soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants