Support doc comments and attributes on nested items

[ironcev]

E.g., while this compiles:

library;

fn fun() {
    struct S {
        field: u8,
    }

    const CONST: u8 = 0;
}

trying to attribute or comment nested items will result in "Expected an expression." error on every doc comment or attribute:

library;

fn fun() {
    /// Comment.             // <<<--- ERROR: Expected an expression.
    #[allow(dead_code)]      // <<<--- ERROR: Expected an expression.
    struct S {
        /// Comment.         // <<<--- ERROR: Expected an expression.
        #[allow(dead_code)]  // <<<--- ERROR: Expected an expression.
        field: u8,
    }

    /// Comment.             // <<<--- ERROR: Expected an expression.
    #[allow(dead_code)]      // <<<--- ERROR: Expected an expression.
    const CONST: u8 = 0;
}

[mexes20]

May I handle this issue?

[truthixify]

To resolve this issue, I will investigate why Rust’s parser incorrectly emits “Expected an expression” errors when documentation comments or attributes are used on nested items inside a function body. This behavior deviates from typical expectations, where attributes and doc comments should be allowed on items like structs, constants, or fields—even when scoped within a function.

My approach will be:
• First, reproduce the issue with a minimal test case using the current compiler version.
• Examine the Rust grammar for item definitions within function bodies to understand if this is a limitation by design or a parsing bug.
• Look into how the parser differentiates between expressions and item declarations, and whether it’s mistakenly trying to parse an attribute or doc comment as an expression.
• If it’s a known issue or has been previously discussed (e.g., in a Rust GitHub issue), I’ll review prior efforts and determine where contributions are needed.
• Otherwise, I’ll narrow the source of the error and propose a fix that updates the parser to properly handle attributes and comments in inner item contexts.

I will also write regression tests to ensure that this fix doesn’t break attribute or comment handling elsewhere. Depending on the complexity of the parser modification, this task should take 2 business days. Once implemented and validated, I’ll submit a pull request that references and closes the issue.