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

E0477 triggered with current nightly #101951

Closed
geeklint opened this issue Sep 17, 2022 · 5 comments · Fixed by #102016
Closed

E0477 triggered with current nightly #101951

geeklint opened this issue Sep 17, 2022 · 5 comments · Fixed by #102016
Labels
A-lifetimes Area: lifetime related A-traits Area: Trait system C-bug Category: This is a bug. P-critical Critical priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@geeklint
Copy link
Contributor

I discovered that some code I had previously been using no longer compiles with the current nightly. It gives E0477 which, as other issues have pointed out, is incorrectly described as "no longer emitted by the compiler".

Code

Link to Playground

I expected to see this happen: The code compiles successfully

Instead, this happened: I get this compiler error:

error[E0477]: the type `PrettyCondo<'_>` does not fulfill the required lifetime
  --> src/lib.rs:41:5
   |
41 |     fn add_building(&mut self, _building: &mut PrettyCondo<'_>) {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: type must outlive the anonymous lifetime as defined here
  --> src/lib.rs:41:21
   |
41 |     fn add_building(&mut self, _building: &mut PrettyCondo<'_>) {
   |                     ^

For more information about this error, try `rustc --explain E0477`.
error: could not compile `e0477-test` due to previous error

Result of cargo-bisect-rustc

searched nightlies: from nightly-2022-08-08 to nightly-2022-09-17
regressed nightly: nightly-2022-08-10
searched commit range: f03ce30...34a6cae
regressed commit: 63e4312

bisected with cargo-bisect-rustc v0.6.4

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc 
@geeklint geeklint added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Sep 17, 2022
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Sep 17, 2022
@steffahn
Copy link
Member

steffahn commented Sep 17, 2022

The error message behaves funny, too, with the type must outlive the anonymous lifetime as define here part. If you change the impl to use add_building<'s>(&'s self, ...) then it points to the next anonymous lifetime in the signature. If you change it to also use explitic &'t mut Pretty... in the second argument it points to the '_. Once you've eliminated all of the elided lifetimes, it points to the whole signature instead.

The problem seems to be related to the question whether or not there's an outlives-relation between the two elided lifetimes in &mut PrettyCondo<'_> or &mut <<T as ConstructionFirm>::Builder as BuilderFn<'_>>::Output. If all lifetimes are made explicit in the trait definition and impl, and there's an explicit outlives-relation in the trait definition and impl, then the code compiles.

Should be nightly regression, judging by the regressing commit, @rustbot label -regression-untriaged, +regression-from-stable-to-nightly.

Some more labels, @rustbot label A-lifetimes, A-traits, T-compiler

@rustbot rustbot added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. A-lifetimes Area: lifetime related A-traits Area: Trait system T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed regression-untriaged Untriaged performance or correctness regression. labels Sep 17, 2022
@inquisitivecrystal
Copy link
Contributor

CC @lcnr as the author of the relevant PR.

@lcnr
Copy link
Contributor

lcnr commented Sep 19, 2022

it's caused by this line:

wf_tys.extend(trait_sig.inputs_and_output.iter());

region check is also bad at dealing with ambiguity so it now fails because it probably has two "equally valid" assumed bounds to choose from, so it just chooses neither

going to look into this a bit deeper now

@lcnr
Copy link
Contributor

lcnr commented Sep 19, 2022

my previous understanding was wrong 😅

fixed the issue in #102016

@inquisitivecrystal inquisitivecrystal added P-critical Critical priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Sep 20, 2022
@inquisitivecrystal
Copy link
Contributor

Assigning priority in accordance with the discussion of the Prioritization Working Group.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 24, 2022
…jackh726

implied_bounds: deal with inference vars

fixes rust-lang#101951

while computing implied bounds for `<<T as ConstructionFirm>::Builder as BuilderFn<'_>>::Output` normalization replaces a projection with an inference var (adding a `Projection` obligation). Until we prove that obligation, this inference var remains unknown, which caused us to miss an implied bound necessary to prove that the unnormalized projection from the trait method signature is wf.

r? types
@bors bors closed this as completed in 16de1fd Sep 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: lifetime related A-traits Area: Trait system C-bug Category: This is a bug. P-critical Critical priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants