Recover closing fragment with contents differently

[jakebailey]

Fixes #44154

I don't know if I like this. This effectively does what was noted in #44154 (comment), but does lead to some extra errors and a different JS output which feels undesirable.

[andrewbranch]

I guess my ideal scenario would be

• </Foo> parses as a JsxElement with a zero-length JsxOpeningElement and the error says you're missing a corresponding opening tag
• <></Foo> parses as an unclosed JsxFragment with ^ inside it

It seems like that would pass the assertion in services and be a net improvement on parser errors reported today. But I don't know how difficult that is.

[jakebailey]

It seems like at the moment, having a random </Foo> in your code doesn't actually parse anything JSX related at all (so the first bullet doesn't exist yet), which makes doing the above tricky because by the time we're here trying to parse the end of a fragment, the children for the fragment are already expected to be completed.

[jakebailey]

Hmm, I have an idea here; I'll give it a try.

[jakebailey]

@andrewbranch I made an attempt to implement the setup you suggested; it does seem to work, but it does seem to break auto-fragment closing in one case because now we think the fragment is closed (as opposed to element); the test will fail in the PR if you want to look.

The error's a placeholder for now.

[jakebailey]

This fails right now as it says "any"; I think this test case was wrong originally given I didn't actually declare Foo.

[jakebailey]

I'm sort of worried about this approach because it makes the parser start eating closing tags moreso than before, so if you stick a <> somewhere as you're trying to do something with it, you'll end up with a lot of errors below, at least that's my best guess. Will have to try.

[jakebailey]

This error seems to get dropped because we're eagerly eating up tags after <> (whereas this test assumed that it would stop earlier, and therefore wrote two tests on two different lines).

[jakebailey]

This condition is now impossible due to the change above.

[jakebailey]

The case looks like:

// @Filename: /4.tsx
////const x = <div>
////    <>/*4*/
////    </div>
////</>;

So, we now see the fragment close below and don't offer up a close. Maybe reasonable, maybe not.

[jakebailey]

#52818 is comically better than this.