fix: robustify comment handling in parser

[Rich-Harris]

The more I looked into the parser code (spurred by #17954) the more stuff I found to fix. There's a lot of duplication at present, as well as some subtle bugs. This PR fixes those bugs and removes >130 LOC.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: 726b764

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-svelte-18087-svelte.vercel.app/

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@18087

[Rich-Harris]

Gah — this is failing because the parser is more robust than before (it handles comments inside patterns) but not robust enough. It can't distinguish regex opening characters from division operators, which is a famously annoying problem. Even once you've solved that part, you're still not totally out of the woods, because a \ character inside a [...] doesn't need to be escaped, so the current 'count the number of preceding backslashes' logic isn't bulletproof.

At least part of this would be easier if we had a parsePatternAt equivalent to parseExpressionAt. Maybe we need to build that.

[Rich-Harris]

Ok I updated read_pattern to not use the current 'trick Acorn into parsing it' approach. It's a lot more code, and currently has a lot more bugs, but it means we no longer need to use bracket matching there. WIP

[Rich-Harris]

Putting a pin in this for now. Summary:

• when we want to read a pattern (e.g. the object pattern in each x as { y, z }) we use bracket-matching to know where the pattern ends, so that we can create a fake function expression to pass to Acorn
• unfortunately our bracket-matching logic is flawed — we have two overlapping implementations, but neither robustly handles all cases. match_bracket ignores comments, and as such gets confused if you have unbalanced braces inside comments; find_matching_bracket is more sophisticated, but gets stuck on certain regexes
• an alternative would be to parse patterns ourselves, rather than tricking Acorn into doing the work for us. This presents its own challenges — parsing is complicated, particularly when it comes to attaching comments to nodes
• it turns out the start and end positions of nodes generated using that trick are off by one