Supersedes#16247,closes#16092.

Today, if you have an effect that runs in an infinite loop, you get this somewhat unhelpful log:

Expanding the array usually reveals 10 copies of the same compiled function:

While youcan click through to the[[FunctionLocation]]...

...even that doesn't necessarily tell you where the offending state change occurred.

We can do better. In this PR, we track the site of updates to state that occur inside an effect, then if wedo encounter an infinite loop we can pinpoint those sites:

This works for things like array mutations, and even works for effects that ping-pong (as opposed to the probably-more-common case in which an effect invalidates itself):

$effect(()=>{a=b+1;});$effect(()=>{b=a+1;});

Better yet, this is actuallysimpler than what we currently have — the implementation ofinfinite_loop_guard can be much leaner, andlog_effect_stack anddev_effect_stack are no more.

This PR also adds an explanation of the error. For things like this I prefer progressive disclosure (i.e. link to the docs when it becomes relevant) rather than adding stuff that you have to read upfront, so I view this as an alternative to#16247.

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 withfeat:,fix:,chore:, ordocs:.
• 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 withinpackages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests withpnpm test and lint the project withpnpm lint