Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code (): The current ( , regressed in the past week) output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --The desired result can be achieved by swapping the order of the two statements and . <!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-07 to nightly-2022-06-08 regressed nightly: nightly-2022-06-08 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details are you working on this? I'll probably be investigating this due to it being related to the recent removal of the borrowck migration mode.
I've been working on it a bit, but please feel free to take over this issue!
This actually looks like a particularly difficult issue. I think it's either a bug in , or something weird with the that is convincing us that the correct source for this region error is through the on line 12 of the example. It may also be notable that we end up going thru a when emitting this error. This issue seems to be out of my area of expertise, so I won't claim it. if you can't find a solution then it may be best to hand off to someone with mir-borrowck expertise.
Actually, what I said was totally wrong. This is definitely because we're passing in the wrong when . I think I have a fix for this, though I probably want to eliminate other dummy locations we're passing around mir borrowck... cc sorry for all the pings, but don't keep wasting time on this unless you've made significant progress :stuckout_tongue: claim

Discussion:
.add_element(live_region_vid, location); }); <ins> // HACK(compiler-errors): Constants that are gathered into Body.required_consts // have their locations erased... let locations = if location != Location::START { location.to_locations() } else { Locations::All(constant.span) }; </ins> if let Some(annotation_index) = constant.user_ty { if let Err(terr) = self.cx.relate_type_and_user_type( constant.literal.ty(), ty::Variance::Invariant, &UserTypeProjection { base: annotation_index, projs: vec![] }, <del> location.to_locations(), </del> <ins> locations, </ins> ConstraintCategory::Boring, ) { let annotation = &self.cx.user_type_annotations[annotation_index];

promoted: &Body<'tcx>, ty, san_ty| { <del> if let Err(terr) = verifier.cx.eq_types( ty, san_ty, location.to_locations(), ConstraintCategory::Boring, ) { </del> <ins> if let Err(terr) = verifier.cx.eq_types(ty, san_ty, locations, ConstraintCategory::Boring) { </ins> span_mirbug!( verifier, promoted,

} } else { if let Err(terr) = self.cx.fully_perform_op( <del> location.to_locations(), </del> <ins> locations, </ins> ConstraintCategory::Boring, self.cx.param_env.and(type_op::ascribe_user_type::AscribeUserType::new( constant.literal.ty(),

} } else if let Some(static_def_id) = constant.check_static_ptr(tcx) { let unnormalized_ty = tcx.type_of(static_def_id); <del> let locations = location.to_locations(); </del> let normalized_ty = self.cx.normalize(unnormalized_ty, locations); let literal_ty = constant.literal.ty().builtin_deref(true).unwrap().ty;

self.cx.normalize_and_prove_instantiated_predicates( def_id, instantiated_predicates, <del> location.to_locations(), </del> <ins> locations, </ins> ); } }

--> $DIR/hrtb-just-for-static.rs:24:5 | LL |     want_hrtb::<StaticInt>() <del> |     ^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `Foo` is not general enough </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^^ implementation of `Foo` is not general enough </ins> | = note: `StaticInt` must implement `Foo<&'0 isize>`, for any lifetime `'0`... = note: ...but it actually implements `Foo<&'static isize>`

<ins> trait Foo { const ASSOC: bool = true; } impl<T> Foo for fn(T) {} fn foo(_x: i32) {} fn impls_foo<T: Foo>(_x: T) {} fn main() { impls_foo(foo as fn(i32)); <fn(&u8) as Foo>::ASSOC; //~^ ERROR implementation of `Foo` is not general enough //~| ERROR implementation of `Foo` is not general enough } </ins>

<ins> error: implementation of `Foo` is not general enough --> $DIR/issue-97997.rs:13:5 | LL |     <fn(&u8) as Foo>::ASSOC; |     ^^^^^^^^^^^^^^^^^^^^^^^ implementation of `Foo` is not general enough | = note: `Foo` would have to be implemented for the type `for<'r> fn(&'r u8)` = note: ...but `Foo` is actually implemented for the type `fn(&'0 u8)`, for some specific lifetime `'0` error: implementation of `Foo` is not general enough --> $DIR/issue-97997.rs:13:5 | LL |     <fn(&u8) as Foo>::ASSOC; |     ^^^^^^^^^^^^^^^^^^^^^^^ implementation of `Foo` is not general enough | = note: `Foo` would have to be implemented for the type `for<'r> fn(&'r u8)` = note: ...but `Foo` is actually implemented for the type `fn(&'0 u8)`, for some specific lifetime `'0` error: aborting due to 2 previous errors </ins>