fix: guard contents updated before the guard itself

[hmnd]

Fixes #16850, #16775, possibly #16795

#16631 introduced a bug that results in the effects within guards being evaluated before the guards themselves. I believe iterating the effects in reverse fixes the issue without any further regressions. An alternative approach could be to actually sort effects by depth before updating, but I suspect that would have a greater performance penalty.

Although all tests pass, sorry if I'm missing something obvious! I've never touched the Svelte internals until now :).

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: 41565da

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-16930-svelte.vercel.app/

[github-actions]

Playground

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

[PatrickG]

It seems like this fixes the issue described here - but only for its first occurrence.
Clicking the button once does not log "one" anymore. Clicking it three times still logs "one".
repl with this PR

[dummdidumm]

Can you explain what the tests are supposed to test? Most (haven't checked all but the first 4 do) also pass on main, and some of them have if conditions that are never true.

I think we should reduce this only to the ones that pass with this PR but fail on main.

[hmnd]

Can you explain what the tests are supposed to test? Most (haven't checked all but the first 4 do) also pass on main, and some of them have if conditions that are never true.

I think we should reduce this only to the ones that pass with this PR but fail on main.

The tests I committed were falling (multi-nested was failing against that pr), but I didn't look too closely at the tests commit I cherry picked from the previous PR.

I'll clean those up and take a stab at @PatrickG's issue today.

[hmnd]

It seems like this fixes the issue described here - but only for its first occurrence. Clicking the button once does not log "one" anymore. Clicking it three times still logs "one". repl with this PR

It looks like sorting eager effects by depth does fix this issue, so that may be necessary after all. Perhaps more efficient to sort higher up the chain in mark_reactions... Best to sort when updating, because mark_reactions could be called multiple times for the same batch of effects.