Fn delegation introduced a theoretical syntax regression (regarding weak keyword `reuse`)

[fmease]

Before the experimental fn delegation (#118212, F-fn_delegation `#![feature(fn_delegation)]` ) was introduced, the following code used to compile:

fn main() {
    let reuse = 0;
    reuse < reuse;
}

Now however it leads to

error: expected one of `!`, `(`, `+`, `::`, `<`, `>`, or `as`, found `;`
 --> src/main.rs:3:18
  |
3 |     reuse < reuse;
  |                  ^ expected one of 7 possible tokens

despite reuse supposedly being a weak keyword only. Here, the parser likely treats the reuse < reuse as the start of a delegation item because the second reuse can begin a type in theory (it's looking to parse reuse <$type>::$pathtree; / reuse <$type as $traitref>::$pathtree).

Of course, this is very unlikely to be hit in practice. Moreover, I can't really see a good solution (unbounded look-ahead & backtracking is of course not on the table). In any case, the syntax is temporary.

Other example:

fn main() {
    let reuse = 0;
    reuse << reuse; //~ ERROR expected one of `!`, `(`, `+`, `::`, `<`, `>`, or `as`, found `;`
}

[bjorn3]

Is there much of a use case to allow reuse directly within function bodies as opposed to at the root of a module or impl?

[fmease]

I would say it's as useful as a block-scoped use: Only necessary in rare cases of ambiguity, otherwise merely a somewhat ~stylistic choice by the author (potentially improving local reasoning) and I think frowned upon in most larger codebases (except for enum glob imports above a match maybe).

[petrochenkov]

Is there much of a use case to allow reuse directly within function bodies as opposed to at the root of a module or impl?

The item grammar should generally be the same regardless of context, in macros we don't always know where we are, that's why all items are usually parsed in all contexts.