Add support for writing HTML literals using UTF8 strings

[DamianEdwards]

Summary

Implements #8429 by enabling UTF-8 HTML literal emission for legacy .cshtml code generation when the generated type's inherited base class has a callable:

void WriteLiteral(ReadOnlySpan<byte> utf8HtmlLiteral)

When that overload is available to the generated type, Razor emits HTML literals as C# UTF-8 literals ("..."u8), allowing direct binding to the byte-span overload. If the overload is not available, generation remains the existing string-literal path.

Implementation

• Adds Utf8WriteLiteralDetectionPass for legacy documents to detect UTF-8 WriteLiteral capability from the inherited base type.
• Adds compilation helper logic to find an accessible WriteLiteral(ReadOnlySpan<byte>) overload across the inheritance chain.
• Ensures source-generator execution has the metadata references needed for the same capability detection behavior.
• Preserves existing UTF-8 literal writing flow in code generation once the option is enabled.

Behavior

Given:

@inherits MyUtf8PageBase
<h1>Hello World</h1>

and a base type containing:

public void WriteLiteral(ReadOnlySpan<byte> utf8HtmlLiteral)

generated HTML literal calls are emitted using UTF-8 string literals ("..."u8).

Tests

• MVC integration coverage validates:
  • overload present => emits UTF-8 literals
  • overload absent => keeps string-literal emission
• Source generator tests validate the same positive/negative behavior.
• Supporting language/compiler tests are updated for this implementation.

[davidwengier]

Since this is for .NET 11 anyway, seems like there's plenty of time to get the ROS overload into the runtime. Should also ideally detect whether such an overload exists or not, an error if not, then people can polyfill easily on older runtimes.

Also should probably have a LDM about this :)

[DamianEdwards]

Since this is for .NET 11 anyway, seems like there's plenty of time to get the ROS overload into the runtime.

The intent wasn't to get an overload into the runtime, at least not at this time. While we certainly could do that, it would make it slower in that case, not faster, as it would then convert from UTF8 bytes to string to place in MVC's output buffering infrastructure, which then turns it back to UTF8 bytes again when writing to the response. Overhauling MVC's output writing to support UTF8 bytes is a much larger undertaking, but of course this change to Razor would be required first.

For now, the goal here is to enable other .cshtml-based scenarios (i.e. non-MVC) to leverage this support and get the performance benefits, e.g. Razor Slices.

Should also ideally detect whether such an overload exists or not, an error if not, then people can polyfill easily on older runtimes.

We don't do this for other directives when custom base classes are being used AFAIK, e.g. if I use @inherits to set the base class to a type with no methods at all, the Razor compiler will simply emit code that doesn't compile due to missing members to call/overload, i.e. the *.cshtml contract as to what's assumed to exist on the base types is implicit.

Also should probably have a LDM about this :)

Didn't realize we discussed Razor compiler stuff there now, cool. LMK what the process is.

[davidwengier]

For now, the goal here is to enable other .cshtml-based scenarios (i.e. non-MVC)

That at least answer my other (unasked) question about why this is .cshtml only.

Didn't realize we discussed Razor compiler stuff there now, cool. LMK what the process is.

Oh, I don't mean the C# LDM. There has been one Razor LDM meeting so far, and I was asleep at the time, but the plan is for there to at least be some committee that can sign off on things, I believe.

We don't do this for other directives when custom base classes are being used AFAIK

I know we don't, but IMO that is not a good thing, and something we should be better about in future. BUT this is also something we can discuss at LDM and see if anyone else agrees with me :)