Fix RestrictChildren incorrectly flagging valid child tags

[davidwengier]

Fixes dotnet/razor#13219

Microsoft Reviewers: Open in CodeFlow

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This pull request addresses dotnet/razor#13219 by adjusting how RestrictChildren/AllowedChildren constraints are validated during tag helper resolution so valid child tags aren’t incorrectly flagged after legacy resolution flattens unmatched elements into HTML content.

Changes:

• Moves AllowedChildren validation earlier in DefaultTagHelperResolutionPhase (before unresolved children are resolved/flattened), and extends validation to understand UnresolvedElementIntermediateNode children.
• Uses the TagHelperBinder during validation to recognize when a prefixed unresolved element would bind as a tag helper (so the prefix can be stripped for AllowedChildren comparisons).
• Adds/extends integration tests to cover non-tag content and the reported regression scenario.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Razor/src/Compiler/Microsoft.CodeAnalysis.Razor.Compiler/src/Language/DefaultTagHelperResolutionPhase.cs	Validates AllowedChildren before child resolution and adds unresolved-element handling using the binder to preserve tag names for correct RestrictChildren behavior.
src/Razor/src/Compiler/Microsoft.AspNetCore.Razor.Language/test/DefaultRazorIntermediateNodeLoweringPhaseIntegrationTest.cs	Adds integration coverage for RZ2009/RZ2010 and a WorkItem regression test ensuring allowed markup children don’t produce diagnostics.

[davidwengier]

This used to report RZ2009 (invalid non-tag content), but now reports RZ2010 (invalid child tag) which seems more appropriate, since its the div that is wrong.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/Razor/src/Compiler/Microsoft.CodeAnalysis.Razor.Compiler/src/Language/DefaultTagHelperResolutionPhase.cs:546

• prefix + parentTagName is concatenated inside the per-child loop, creating a new string allocation each time we need to check whether a prefixed unresolved child would bind as a tag helper. Since parentTagName is constant for this validation pass, precompute the prefixed parent tag name once outside the loop and reuse it in the binder lookup to avoid repeated allocations in a hot compilation path.

                    binder.GetBinding(
                        childTagName,
                        unresolvedElement.AttributeData,
                        prefix + parentTagName,
                        parentIsTagHelper: true) != null)

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/Razor/src/Compiler/Microsoft.CodeAnalysis.Razor.Compiler/src/Language/DefaultTagHelperResolutionPhase.cs:345

• Allowed-children validation now runs (1) once before the reverse walk, and (2) per original UnresolvedElementIntermediateNode after ResolveElement. If ResolveElement resolves a StartTagOnly tag helper, it can promote parsed body content into parent.Children as new siblings (see the StartTagOnly promotion logic in ResolveElement). Those newly inserted siblings are added after the current index while this loop is iterating backwards, so they won’t be visited/validated here, and they also weren’t present during the initial ValidateAllowedChildren pre-pass. This can allow invalid direct children to slip through (or miss RZ2009/RZ2010) when StartTagOnly promotion occurs under an AllowedChildTags constraint.

Consider adding a validation step for any siblings inserted by StartTagOnly promotion (e.g., detect resolvedTagHelper.TagMode == TagMode.StartTagOnly and validate the promoted range), or restructure the logic so all final direct children are validated without reintroducing the original false-positive issue for flattened plain-HTML elements.

                var resolvedTagHelper = ResolveElement(
                    parent, i, elementNode, binder, prefix, usedHelpers, in context, tagHelperParent);

                if (allowedChildrenString != null)

[davidwengier]

/backport to release/10.0.4xx

[github-actions]

Started backporting to release/10.0.4xx (link to workflow run)