Skip to content
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

maybe regression related to GATs #105878

Open
phynalle opened this issue Dec 18, 2022 · 7 comments
Open

maybe regression related to GATs #105878

phynalle opened this issue Dec 18, 2022 · 7 comments
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@phynalle
Copy link

phynalle commented Dec 18, 2022

Code

I tried this code:

trait Foo {
    type Gat<'a> where Self: 'a;
    fn bar(&self) -> Self::Gat<'_>;
}

impl<T: Foo> Foo for Option<T> {
    type Gat<'a> = Option<<T as Foo>::Gat<'a>> where Self: 'a;
    fn bar(&self) -> Self::Gat<'_> {
        self.as_ref().map(Foo::bar)
    }
}

Version it worked on

The code is compiled on Rust 1.65

Version with regression

The code is not compiled on current stable(1.66), beta, and nightly with error:

error: `T` does not live long enough
 --> src/lib.rs:9:9
  |
9 |         self.as_ref().map(Foo::bar)
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `playground` due to previous error
@phynalle phynalle added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Dec 18, 2022
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Dec 18, 2022
@phynalle
Copy link
Author

I found out that adding static bound (e.g. impl<T: Foo + 'static> ...) fixes the compile error.

but I don't know which code is correct.

@jruderman
Copy link
Contributor

Regression in nightly-2022-09-22 from #100096. While that PR fixed a soundness hole, I don't think it was expected to affect stable code. CC @compiler-errors, @jackh726, @estebank.

@compiler-errors compiler-errors added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Dec 18, 2022
@compiler-errors
Copy link
Member

Ugh, yeah, this is probably due to the fact we need to prove something like for<'a> Self: 'a on the GAT in order to prove that for<'a> T::Gat<'a>: Sized

@jruderman
Copy link
Contributor

@rustbot label -regression-untriaged +regression-from-stable-to-stable

@rustbot rustbot added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. and removed regression-untriaged Untriaged performance or correctness regression. labels Dec 18, 2022
@apiraino
Copy link
Contributor

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

@rustbot rustbot added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Dec 21, 2022
@jackh726
Copy link
Member

I'm split on what we should do here. There's really two options (because I fix is some time away):

  1. Revert a fn pointer doesn't implement Fn/FnMut/FnOnce if its return type isn't sized #100096
  2. Deal with it

#100096 was a soundness fix, but one that's been open for a while. This bug is just another instance of a large list of issues all related. I'm not sure that reverting a soundness fix is a good choice, even for stable behavior.

A decent middle ground would be to extend the "this might be a bug" error to this case.

@estebank
Copy link
Contributor

Deal with it

That would require the error to at least suggest the 'static bound to unblock people.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 24, 2023
…ligations, r=lcnr

Return nested obligations from canonical response var unification

Handle alias-eq obligations being emitted from `instantiate_and_apply_query_response` in:
* `EvalCtxt` - by processing the nested obligations in the next loop by `new_goals`
* `FulfillCtxt` - by adding the nested obligations to the fulfillment's pending obligations
* `InferCtxt::evaluate_obligation` - ~~by returning `EvaluationResult::EvaluatedToAmbig` (boo 👎, see the FIXME)~~ same behavior as above, since we use fulfillment and `select_where_possible`

The only one that's truly sketchy is `evaluate_obligation`, but it's not hard to modify this behavior moving forward.

From rust-lang#109037, I think a smaller repro could be crafted if I were smarter, but I am not, so I just took this from rust-lang#105878.

r? `@lcnr` cc `@BoxyUwU`
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. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants