Skip to content

LUB of a bivariant parameter is not fully general #41044

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

Open
nikomatsakis opened this issue Apr 3, 2017 · 3 comments
Open

LUB of a bivariant parameter is not fully general #41044

nikomatsakis opened this issue Apr 3, 2017 · 3 comments
Labels
C-bug Category: This is a bug. I-needs-decision Issue: In need of a decision. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Apr 3, 2017

In #40570, I removed bivariance somewhat aggressively. One area where we are not quite doing the right thing, it appears, is when computing the LUB/GLB of a bivariant type parameter. The code currently just picks one side, which seems clearly wrong, but I was not able to craft a test case exploiting that. Therefore, opening an issue to revisit later if we can get a concrete test case.

This comment explains my preferred fix:

I think you are correct about the eventual result but I wouldn't expect it to be derived immediately from the LUB computation. Since the last parameter is considered "bivariant" (i.e., derived from constraints on the others), I'd expect that the last parameter simply gets a fresh variable, and that trait selection will constrain it (ultimately) to be 'c. In other words, the result from LUB itself would be Foo<fn() -> &'?0 u32, '?1> where 'a: '?0 and 'b: '?0, but enforcing the WF requirements would ultimately constraint '?1 = '?0.

However, it occurs to me that I'm not entirely sure where these WF requirements would get enforced. Much of the code assumes that the resulting types from LUB operations etc are well-formed, and hence I'm not sure when we would add such an obligation. (One possibility is to have the LUB/GLB operation itself produce an obligation, at least if bivariance is involved, given that this is now a possibility.)

@Mark-Simulacrum Mark-Simulacrum added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 20, 2017
@Mark-Simulacrum Mark-Simulacrum added C-bug Category: This is a bug. I-needs-decision Issue: In need of a decision. labels Jul 27, 2017
@pierwill
Copy link
Member

I'm interested in looking into this :) @rustbot claim

@pierwill
Copy link
Member

pierwill commented Mar 8, 2022

@rustbot release-assignment

@lcnr
Copy link
Contributor

lcnr commented Oct 3, 2024

This issue is irrelevant by now as we Lub and Glb is only used during HIR typeck which doesnt do any region checking

edit: keeping this open as long asd these relations still exist though 🤔 as it is incorrecct non-the less

@lcnr lcnr closed this as completed Oct 3, 2024
@lcnr lcnr reopened this Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. I-needs-decision Issue: In need of a decision. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants