fix: optimize consecutive if blocks

[Sean-Kenneth-Doherty]

Description

Fixes #10049.

This adds a conservative compiler-analysis optimization for consecutive nested {#if} blocks. When an {#if} contains only another simple {#if} and both conditions are sync, call-free, assignment-free, blocker-free, and have no else branch, the compiler merges them into one outer && inner condition and reuses the inner body.

That avoids generating an extra client $.if block and nested server if for common template shapes like:

{#if iconData}
  {#if iconData.paths}
    ...
  {/if}
{/if}

The optimization is disabled when preserveWhitespace is enabled, because whitespace-only text around nested blocks can be observable in that mode.

Validation

• pnpm --filter svelte build
• FILTER=/nested-if-/ pnpm test snapshot
• pnpm test snapshot
• pnpm --filter svelte check
• pnpm lint
• git diff --check

[changeset-bot]

🦋 Changeset detected

Latest commit: 9817754

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

[Sean-Kenneth-Doherty]

Local validation on the current head (9d30aa9):

• pnpm install --frozen-lockfile -> completed cleanly
• FILTER=/nested-if-/ pnpm test snapshot -> 1 file passed, 2 tests passed
• pnpm --filter svelte build -> passed
• pnpm --filter svelte check -> passed
• pnpm test snapshot -> 1 file passed, 34 tests passed
• pnpm lint -> ESLint and Prettier checks passed
• git diff --check origin/main...HEAD -> clean

The build/check steps did not leave generated-file drift; the branch is clean locally after validation.

[dummdidumm]

thank you! while this all makes sense and is well-written, I'm not entirely sure if we should actually do this. It's an edge case I would say and I'm not sure the additional code is worth it. Waiting on opinions from other maintainers.

[dummdidumm]

We bail in quite a few cases here - I do wonder if this is still worth the additional code

[Rich-Harris]

I'm inclined to agree with @dummdidumm here — this does microscopically improve performance in the cases where this optimisation can be applied, but they're few and far between, and the original test case should just be rewritten to be a single block which would make the source code more readable.

[Sean-Kenneth-Doherty]

Thanks for taking a look. That makes sense to me; the edge-case win is not worth carrying extra compiler complexity here. I will close this out.