Support for + use<..> precise_capturing syntax

[traviscross]

We're planning to stabilize #![feature(precise_capturing)] ahead of Rust 2024 (in all editions). This feature allows one to write:

fn captures<'a: 'a, 'b: 'b, T>() -> impl Sized + use<'b, T> {}
//                                  ~~~~~~~~~~~~~~~~~~~~~~~
//                          This opaque type does not capture `'a`.

fn outlives<'o, T: 'o>(_: T) {}

fn caller<'o, 'a, 'b: 'o, T: 'o>() {
    //        ~~
    //        ^ Note that we don't need `'a: 'o`.
    outlives::<'o>(captures::<'a, 'b, T>());
}

Playground link

That is, it allows for the precise capturing of generic parameters in RPIT-like impl Trait opaque types (the initial stabilization will require all in scope type and const parameters to be included in the use<..> bound; see the stabilization report for other restrictions). We need this to stabilize so that we can stabilize the Lifetime Capture Rules 2024 (RFC 3498) in Rust 2024. These are lang team priority items for the Rust 2024 edition.

Currently r-a gives errors about this syntax:

fn captures<'a: 'a, 'b: 'b, T>() -> impl Sized + use<'b, T> {}
//                                              ~   ~~ ~  ~ ^ Syntax Error: expected an item
//                                              |   |  |  ^ Syntax Error: expected BANG
//                                              |   |  |  ^ Syntax Error: expected `{`, `[`, `(`
//                                              |   |  ^ Syntax Error: expected an item
//                                              |   ^ Syntax Error: expected SEMICOLON
//                                              ^ Syntax Error: expected a block

The earliest this syntax could conceivably stabilize is with Rust 1.82, which will branch on 2024-08-30 and will be released on 2024-10-17.

Tracking:

• Tracking issue for precise_capturing syntax rust#123432

[Veykril]

Given we dont really handle opaque types wrt to their generic captures fully anyways I reckon it ought to be enough for us to merely add the parsing here for starters which is a simple change (ah thats what the issue is mainly asking for anyways whoops)

[Veykril]

Needs a corresponding grammar rule in https://github.com/rust-lang/rust-analyzer/blob/master/crates/syntax/rust.ungram
Then run cargo codegen grammar and finally edit the parser here

rust-analyzer/crates/parser/src/grammar/generic_params.rs

Lines 141 to 186 in e9afba5

	fn type_bound(p: &mut Parser<'_>) -> bool {
	let m = p.start();
	let has_paren = p.eat(T!['(']);
	match p.current() {
	LIFETIME_IDENT => lifetime(p),
	T![for] => types::for_type(p, false),
	T![?] if p.nth_at(1, T![for]) => {
	// test question_for_type_trait_bound
	// fn f<T>() where T: ?for<> Sized {}
	p.bump_any();
	types::for_type(p, false)
	}
	current => {
	match current {
	T![?] => p.bump_any(),
	T![~] => {
	p.bump_any();
	p.expect(T![const]);
	}
	// test const_trait_bound
	// const fn foo(_: impl const Trait) {}
	T![const] => {
	p.bump_any();
	}
	// test async_trait_bound
	// fn async_foo(_: impl async Fn(&i32)) {}
	T![async] => {
	p.bump_any();
	}
	_ => (),
	}
	if paths::is_use_path_start(p) {
	types::path_type_bounds(p, false);
	} else {
	m.abandon(p);
	return false;
	}
	}
	}
	if has_paren {
	p.expect(T![')']);
	}
	m.complete(p, TYPE_BOUND);
	true
	}

If new inline parser tests were added you can then run cargo codegen inline-parser-tests to regenerate those

[winstxnhdw]

I’ll give this a go :)