Support syntax for one-line trait reuse

[aerooneqq]

This PR adds support for reusing the whole trait with a one-line reuse syntax and is part of the delegation feature #118212:

trait T {
  fn foo(&self);
}

struct S;
impl T for S { ... }

struct Wrapper(S);
reuse impl T for Wrapper { self.0 }

The core idea is that we already have support for glob reuse, so in this scenario we want to transform one-line reuse into a trait impl block with a glob reuse in the following way:

//Before
reuse impl T for Wrapper { self.0 }

//After
impl T for Wrapper {
  reuse T::* { self.0 }
}

It seems like this task can be solved during parsing stage, when we encountered a one-line trait reuse, we can expand into this impl block right away, and the code which was already written to expand glob delegations will take care about the rest. We will copy trait path into glob reuse path.

The implementation of the transformation reuses already existing methods for impl parsing, however, we do not parse inner impl items, instead we parse "inner items" as delegation body. Thus, we do not have to deal with generics, consts, unsafe and other impl related features.

Other syntax possibility is trying to shorten one-line reuse by replacing impl keyword with reuse keyword:

reuse T for Wrapper { self.0 }

In this case implementation may become more complicated, and the syntax more confusing, as keywords such as const or unsafe will precede reuse, and there are also generics:

unsafe reuse<T1, T2> T for Wrapper { self.0 }

In the first (currently implemented) version reuse is placed in the beginning of the item, and it is clear that we will reuse trait implementation, while in the second, shorter version, the reuse keyword may be lost in generics and keywords that may precede impl.

r? @petrochenkov

[petrochenkov]

Why disabling the diagnostics here instead of using the old check_impl_frontmatter?

[petrochenkov]

Suggested change

	Ok(ItemKind::DelegationMac(Box::new(DelegationMac {
	ItemKind::DelegationMac(Box::new(DelegationMac {

Ok can be moved out of the condition.

[petrochenkov]

This is a semantic error, not a parsing error.
I think we can just generate a negative trait impl here, it will be reported later.

[petrochenkov]

Oh, so you cannot do things like impl my_trait!() for Type {}.
This is good, it means the impl delegation desugaring won't result in duplicating macro calls, and the parsing-time treatment of the feature is not a very bad approximation.

[petrochenkov]

Items in the trait path will still get duplicated.
reuse impl Trait<{ struct S; 0 }> for Type {}
->

impl Trait<{ struct S; 0 }> for Type {
  reuse Trait<{ struct S; 0 }>::*;
}

, but that's probably ok because the glob delegation will duplicate the item too (?)

  reuse Trait<{ struct S; 0 }>::foo;
  reuse Trait<{ struct S; 0 }>::bar;
  reuse Trait<{ struct S; 0 }>::baz;

Could you maybe add an AST pretty-printing test for this case?