Allow explicit lifetime arguments (behind new #![feature(late_bound_turbofishing)]) and prevent explicit lifetime arguments where they do not appear in a function signature

[addiesh]

r? oli-obk

note: commit dd17e77 is part of another PR (#159403) and needs to be merged before this does (I'll rebase the commit out when it gets merged, which should be soon)

This PR is a little bit big (and probably super messy). here's what it changes/adds:

• add a feature flag late_bound_turbofishing for the new behavior
  • Tracking Issue for early/late bound parameter cleanup and late-bound turbofishing #156581
• change to prevent explicit lifetime arguments where they do not appear in a function signature
  • Elided early-bound lifetime parameters (due to associated types) can be turbofished #154490

addie's checklist:

• make sure that the late-bound lifetime specification makes sense and isn't just failing silently
  • i do not know how to do this!!! this is some type system wizardry that escapes me. I will need help with this
  • i added one (1) test case to check and it fails (here)
• fix the the turbofishing doesn't work because late-bound lifetimes aren't being counted right now

so what:

1. this will now compile:

#![feature(late_bound_turbofishing)]

fn foo<'a>(b: &'a u32) -> &'a u32 { b }

fn main() {
    let f = foo::<'static>;
}

...and if the feature gate is missing, a diagnostic will be reported.

2. this snippet (taken from this issue) will now fail to compile:

trait Trait {
    type Assoc<'a>;
}

fn do_thing<'b, T: Trait>(_: Option<<T as Trait>::Assoc<'_>>) -> (&i32, &'b i64) {
    todo!()
}

fn foo<T: Trait>() {
    do_thing::<'static, 'static, T>(None);
}

...although its diagnostic probably could stand to be improved.

ty :3

And on the pull request these words appear:
"My name is Fishymandias, fish of fish:
Look on my Rust, ye Reviewer, and despair!"

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @oli-obk (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

[addiesh]

this needs to fail, but currently it's not... don't know how to fix

View changes since the review

[oli-obk]

isn't this just the usual FnDef outlives issue that already exists without your PR?

[addiesh]

Oops- I think so? But I;m not sure. the following (which is early-bound afaik) compiles when it shouldn't(?) in the rust playground

fn require_static<T: 'static>(_: T) {}

fn foo<'a: 'a>(b: &'a u32) -> &'a u32 { b }

fn bar<'a>(_: &'a u32) {
    let f = foo::<'a>;
    require_static(f);
}

fn main() {
    let x = 4;
    {
        bar(&x);
    }
}

[addiesh]

that CI run didn't give a good backtrace so to save future me from agony, the problem is here

rust/compiler/rustc_hir_analysis/src/hir_ty_lowering/generics.rs

Line 511 in fcf1f4c

param_counts.lifetimes - hidden_lifetimes + late_bound_lt_count;

[addiesh]

this is gonna be rough:

[rustbot]

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

HIR ty lowering was modified

cc @fmease