Fix asm sym operand parsing for parenthesized expr fragments

[railgun-0402]

Fixes #21582

Summary

When capturing a path via $e:expr, macro expansion treats it as Fragment::Expr and wraps it in parentheses to preserve operator precedence.
This results in sym (generic::<i32>), but the existing parser expected a path immediately after sym and failed when seeing (, leading to a parse failure and a bogus typed-hole diagnostic.

Changes

• Parse the operand after sym as an expression
• During lowering, extract a path from the expression (so parenthesized forms are handled correctly)

Why this approach

This keeps parsing more permissive while keeping the semantic requirement (“sym expects a path”) enforced during lowering.

Testing

• Added/updated regression test for Invisible delimiters after asm sym operand causes parsing errors #21582
• cargo test (and any focused test targets you ran)

AI Usage

AI disclosure:

I used ChatGPT to help draft the PR description and clarify the root-cause explanation.
The implementation and tests were written and validated by me.

[ChayimFriedman2]

Please note that we require disclosure of AI usage, if you used them.

[oxalica]

I'm not sure if it is good to overly relax the syntax to accept any sym <expr>, which is not accepted by rustc currently. Note that rustc will reject it if you write sym (func) directly (see also syntax reference).

[railgun-0402]

Good point — I agree we shouldn’t accept a broader sym syntax than rustc.

The problematic case here is $e:expr in macro expansion, where the operand can be wrapped in invisible delimiters for precedence, even though users didn’t write parentheses.

I’ll adjust the change to keep the syntax strict (path-only), and only handle the invisible-delimiter wrapping so that sym (func) written directly is still rejected, matching rustc. I’ll also add a regression test for sym (func) to ensure we stay compatible.