Prevent explicitly specifiying lifetime arguments to functions when the parameters are not visible in the type signature.

[addiesh]

This is meant to fix #154490:

trait Trait {
    type Assoc<'a>;
}

// zero explicit generic lifetimes
fn do_thing<T: Trait>(_: Option<<T as Trait>::Assoc<'_>>) -> &i32 {
    todo!()
}

fn foo<T: Trait>() {
    // Previously, this would NOT cause any errors.
    // this PR makes it error out.
    do_thing::<'static, T>(None);
}

This started as a larger PR (#160471) but these changes work on their own.
Eventually, that PR should introduce the same checks for late-bound lifetimes.

[rustbot]

HIR ty lowering was modified

cc @fmease

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @mejrs (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 18 candidates

[mejrs]

Isn't this a breaking change?

[addiesh]

I don't think so? Afaik, the only way that this can happen is through a bug.

It may be worth a crater run to check to see if anyone is relying on this behavior though?

[mejrs]

Well, that depends on how breaking it is :)

[oli-obk]

@bors try

[rust-bors]

☀️ Try build successful (CI)
Build commit: 36e0a7e (36e0a7eac2392bdd51fab6e7ff1d8c0e42d33bf6)
Base parent: 22950ab (22950ab9e29e11620a10905f027f141ea126966e)

[oli-obk]

@craterbot check

[craterbot]

👌 Experiment pr-160581 created and queued.
🤖 Automatically detected try build 36e0a7e
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-160581 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-160581 is completed!
📊 9 regressed and 2 fixed (1065567 total)
📊 6381 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

Footnotes

1. re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-160581/retry-regressed-list.txt ↩

[addiesh]

ok so, that's good! only one crate actually impacted, 4 different versions of it though... Unsurprising to me that it's a math-related crate (https://crates.io/crates/faer) given how those love generics. @mejrs, what do you think is the way forward here? Looking at the results, the four broken versions (or at least, the four versions with consumers) are 0.19.1, 0.19.4, 0.20.1, and 0.20.2. The most recent version of the crate does not contain the now-invalid behavior, so updating could be a reasonable path forward for the library's consumers.

The easiest place to see the behavior is defined here and used here. The function has an elided lifetime parameter and is turbofished using '_. Excerpt:

fn _something() {
	// sparse/linalg/qr.rs:1388
	let mut s_L = crate::mat::from_column_major_slice_mut_generic::<'_, E, _, _>(
		s_L.into_inner(),
		s_pattern.len() + s_ncols,
		s_ncols,
	);
}

// mat/matmut.rs:2231
#[track_caller]
pub fn from_column_major_slice_mut_generic<E: Entity, R: Shape, C: Shape>(
	slice: SliceMut<'_, E>,
	nrows: R,
	ncols: C,
) -> MatMut<'_, E, R, C> {
	/* ... */
}

[mejrs]

updating could be a reasonable path forward for the library's consumers.

It looks like all of 0.19 and 0.20 are affected, and there exist no semver compatible (minor) versions to upgrade to. So "reasonable" is up for debate.

What you can do right now is to reach out to the crate maintainer and ask them pretty please to release 0.20.3 and 0.19.6 versions with a fix. Then everyone affected can just cargo update to get a fixed version. There are some things that make that annoying, though:

• it doesn't look like they made tags for < 0.22 releases, so someone will have to figure out what git revs corresponds with it
• there's a yanked 0.19.5 version (with no minor release after it), so a new 0.19.6 release would need to be semver compatible with whatever is in that version.

I'd suggest doing the above and then nominating it for the relevant team to discuss whether to accept the breakage. For that it would be very helpful if the above has been done.