Fix @@ escape handling in component attribute values

[Copilot]

Summary of the changes

@@ escape sequences now work consistently in component attribute values. Previously worked in HTML content but failed in component attributes with "complex content not supported" error.

Root cause: During IR lowering, @@ created separate markup nodes that triggered the complex content validator. The ephemeral second @ token wasn't being properly merged.

Changes:

• Modified VisitAttributeValue() in DefaultRazorIntermediateNodeLoweringPhase.cs to extract literal @ tokens from @@ patterns and merge them into the attribute value string before creating IR nodes
• Applied fix to both tag helper visitor classes (standard and component file kind)

Example:

@* Now works - passes literal string "@currentCount" *@
<Weather Value="@@currentCount" />

@* Also works with mixed content *@
<Weather Value="@@count @someVar" Title="@@title" />

Test updates:

• Added parser tests for escaped attribute values
• Added integration tests for component code generation
• Updated ComplexTagHelpers baseline (source position tracking changed)

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• bcnvsblobprodcus378.vsblob.vsassets.io
  • Triggering command: /usr/share/dotnet/dotnet dotnet test src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj --filter FullyQualifiedName~HtmlAttributeTest.EscapedAttributeValue --no-build --no-restore de/node/bin/grep stBase.*{ rPresentationPar-l rep grep -l stBase.*{ ation/MessagePack/Formatters/CachedStringFormatter.cs nfig/composer/vendor/bin/grep stBase.*{ ationParams.cs de/node/bin/grepabstract.*class.*ParserTestBase\|class.*ParserTestBase.*{ grep (dns block)
  • Triggering command: /usr/share/dotnet/dotnet dotnet test src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj --filter FullyQualifiedName~HtmlAttributeTest.EscapedAttributeValue --no-restore ation/FetchTagHe--projects /home/REDACTED/.cosrc/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor--noprofile stBase.*{ Service.cs k/_temp/ghcca-no.tools | has("runtimes") grep -l stBase.*{ kspaces/Serialization/MessagePack/Formatters/TagHelpers/ComponentMetadataFormatter.cs rep stBase.*{ r.cs /home/REDACTED/.co--restore grep (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>@@ escape works in HTML content but fails in component attribute values – inconsistent Razor behavior</issue_title>
<issue_description>In Razor syntax, @@ is documented as the way to escape a literal @ character in markup output.

Example (works as expected):

<p>@@hello</p>

This renders @hello in HTML output.

However, the same escape syntax does not work in component attribute values:

<Weather Value="@@currentCount" />

This results in a Razor compilation error, because the presence of @ switches the parser into C# expression mode, and @@currentCount is not a valid expression.

---

Observed Behavior

• @@ is recognized and processed in HTML content
• @@ is not recognized in component attribute values
• Component attributes do not appear to have an escape or literal-string mechanism equivalent to HTML markup

---

Expected / Questioned Behavior

From a user’s perspective, this is surprising:

<Weather Value="currentCount" />

is accepted and treated as a literal string, but:

<Weather Value="@@currentCount" />

is rejected, even though it could unambiguously mean the literal string "@currentCount".

This raises a few questions:

1. Is this behavior intentional by design, or a limitation of the current Razor compiler structure?
2. If intentional, is there documentation explaining why @@ escape applies only to markup output and not to component attribute values?
3. Would it be feasible (or desirable) to support literal escaping in component attributes for consistency, or is this explicitly out of scope?

---

Rationale

I understand that component attributes are expression-based and intentionally do not support mixed C# and markup content.

However, this scenario does not require mixed content — it only requires escaping a literal @.

The current behavior feels inconsistent because:

• @@ is part of Razor syntax
• Its validity depends on context in a way that is not clearly documented
• This can lead users to assume the feature is missing or incomplete rather than intentionally unsupported

---

Summary

This issue is not a request for string templating in component attributes, but a request for clarification (or reconsideration) of why Razor escape syntax behaves differently between:

• HTML markup
• Component attribute values

Even explicit documentation of this limitation would help reduce confusion.
</issue_description>

<agent_instructions>Allow a user to escape a literal @ character in a component attribute value</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes @@ escape works in HTML content but fails in component attribute values – inconsistent Razor behavior #12663

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.