feat: more complex partial evaluation

[Ocean-OS]

Like #15781, this PR will add more partial evaluation to the compiler. Some of the goals here are:

• Prototype methods for literals:

<script>
    let greeting = 'Hello, world!';
</script>
<h1>Hello, {greeting.slice(-6)}</h1> <!-- compiled to Hello, world! -->

• Maybe more globals?
• Function analysis
• Maybe TypeScript type annotations/assertions?
• Maybe add evaluated stuff to the template?

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]

⚠️ No Changeset found

Latest commit: 9a1eb6e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[svelte-docs-bot]

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

[github-actions]

Playground

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

[Ocean-OS]

One thing I realized we should optimize is {#if } blocks, which would alleviate the need for a block effect if the condition is statically analyzable. Are there any possible caveats to this?

[Ocean-OS]

Am considering either adding a ton of tests to snapshot or making a new testing folder dedicated to partial evaluation, I'll look into about how many tests I should make...

[Rich-Harris]

Thank you but I really don't think this is a good direction to go in. It adds a lot of complexity for a benefit that is mostly academic, and which mostly belongs at the level of a general purpose optimiser.

It can also be counterproductive (think str.repeat(1000)) and, as we saw with Math.random(...), is error-prone. We learned this lesson back in the day with Prepack, which was a much more sophisticated implementation of the same basic idea — on paper the effect was dramatic, but it never went anywhere because in practice the idea just doesn't work in real apps.

Am actually rethinking #15494 and #15781 and plan to partly revert them. We shouldn't be inlining these values, but we should be using our domain-specific knowledge to emit code that can be more easily optimized.

For example in a case like <h1>Hello {name}!</h1> we don't need to inline name, we just need to avoid the $.escape. Minifiers will take it from there:

[Ocean-OS]

I see what you mean, but is there really much reason to revert the other PRs? They're much simpler and (according to the ~6000 tests) are error-free.