Skip to content

Conversation

@lcnr
Copy link
Contributor

@lcnr lcnr commented Jun 8, 2022

closes #54105

Should still think about higher ranked equality which currently relies on mutual subtyping.

All other subtyping in the MIR either is fine as both sides are checked for WF or them not being WF is irrelevant. Any type mentioned in the MIR whose the lack of WF checks is an issue probably should get one, regardless of whether we add needs_wf to the TypeGeneralizer.

r? @nikomatsakis cc @rust-lang/wg-nll

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 8, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 8, 2022
/// We could deal with this by checking all types we end up relating
/// for well-formedness. Or at least all types that matter...
///
/// Alternatively, lazily can check whether we encounter a bivariant
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// Alternatively, lazily can check whether we encounter a bivariant
/// Alternatively, we can lazily check whether we encounter a bivariant

@lcnr lcnr closed this Jul 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix "bivariant wf" bug in the NLL subtyping code

4 participants