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.

[railgun-0402]

Hi @oxalica — thanks for the earlier feedback!

I revised the approach to avoid relaxing sym syntax beyond rustc.
Instead of accepting sym <expr>, this PR keeps the operand path-only and fixes the macro-expansion behavior that introduced the problematic parentheses.

• In the macro transcriber, we avoid wrapping path-like expr fragments (e.g. generic::<i32>) in parentheses, since that breaks asm! sym operands coming from $e:expr.
  (Conservative heuristic: requires :: and only allows path-like tokens.)
• Added a regression test for the $e:expr + sym $e case (issue Invisible delimiters after asm sym operand causes parsing errors #21582) to ensure no bogus typed-hole diagnostic.

Could you please take another look at the transcriber heuristic and the test coverage?
Thanks!

[ChayimFriedman2]

No no no. If we're accepting that we should patch something until we fix macros properly (which I'm not sure is a good idea but maybe it is), it is definitely not a good idea to do that in macro_rules general handling. Change the parser to accept parentheses inside sym instead:

rust-analyzer/crates/parser/src/grammar/expressions/atom.rs

Lines 409 to 413 in 4eac290

	} else if p.eat_contextual_kw(T![sym]) {
	dir_spec.abandon(p);
	paths::type_path(p);
	op.complete(p, ASM_SYM);
	op_n.complete(p, ASM_OPERAND_NAMED);

[ChayimFriedman2]

Please squash.

View changes since this review

[railgun-0402]

Squashed!

squashed my commits

[ChayimFriedman2]

Thanks!

View changes since this review