Skip to content

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

Open

Description

@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 `;`
}

Activity

  1. added
    A-parserArea: The lexing & parsing of Rust source code to an AST
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    C-bugCategory: This is a bug.
    on Oct 29, 2025
  2. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Oct 29, 2025
  3. added and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Oct 29, 2025
  4. changed the title [-]Introduction of fn delegation introduced a theoretical syntax regression (regarding weak keyword `reuse`)[/-] [+]Fn delegation introduced a theoretical syntax regression (regarding weak keyword `reuse`)[/+] on Oct 29, 2025
  5. bjorn3 commented on Oct 29, 2025

    @bjorn3
    Member

    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?

  6. fmease commented on Nov 28, 2025

    @fmease
    MemberAuthor

    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).

  7. petrochenkov commented on Nov 28, 2025

    @petrochenkov
    Contributor

    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.

  8. added a commit that references this issue on Mar 9, 2026
  9. added 2 commits that reference this issue on Mar 9, 2026
  10. added a commit that references this issue on Mar 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-parserArea: The lexing & parsing of Rust source code to an ASTC-bugCategory: This is a bug.F-fn_delegation`#![feature(fn_delegation)]`P-lowLow priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions