Support closed void tags with content in code blocks

[jjonescz]

Fixes #8460.
Fixes #7258.

Void tags (e.g., <col>, <link>) in code blocks could not have a content and a closing tag, so everything after them was considered to be code. But if the tag is actually a component, I think that behavior doesn't make sense (see the associated issues).

Reworked the fix

[333fred]

I don't think I have time to walk through these changes before I'm out for the rest of the week. @jjonescz, when I get back I could use a walkthrough of how we support this outside of code blocks in the parser today.

[jjonescz]

how we support this outside of code blocks in the parser today

This problem really only appears inside code blocks. The parser consumes code, then encounters <, starts consuming markup, and after <input> it doesn't know whether it should continue parsing code (if <input> is void self-closed tag) or markup (if it's a component that will be closed later). Outside code blocks, it always parses markup by default except when explicitly told not to (by @ transition)

[333fred]

This is likely not tracking enough info; what if there are multiple? Please add some tests with multiple tags, some of which should be treated as void tags, some of which should not, all within a markup block inside a code block.

[jjonescz]

Good catch, thanks. I'm not yet sure if this will be difficult to fix, need to investigate. But alternatively we could give up this PR but at least emit some better error/warning when trying to use a component named like void tag.

[333fred]

Better backtracking support in general will be useful trying to fix some of the nested } error recovery scenarios, so I think it would be useful to invest in fixing, even if more complex.

Now, whether it's good language design to allow components to shadow void tags... that's an entirely different question 😆. I would have forbidden it and required an escape syntax of some kind, like C# does for identifiers named after keywords.

[chsienki]

@jjonescz Are we likely to keep going with this?

[jjonescz]

Are we likely to keep going with this?

@chsienki This probably needs a razor language design discussion if we want to support it. In the meantime we could add a warning (perhaps as part of warning wave support which I have another PR open for). We would need to warn at the component declaration itself to tell people they should rename it because it's problematic.

Hm, maybe we could also implement some "force this to be parsed like a component", e.g., adding a bang in front of its name (something like that is already supported for tag helpers IIRC).

I think fully-qualyifing the component with its namespace might be also a good workaround for users. Maybe tooling could suggest that. Or the compiler could suggest it via some warning/info diagnostic at the problematic use site of the component.