Better effect stack logging

[Rich-Harris]

Describe the problem

See #13231 (comment)

Describe the proposed solution

Attach location information to effects in development, so that it can be used when generating the error message. For simple cases where there's only a single effect involved we can do this sort of thing:

Uncaught Svelte error: effect_update_depth_exceeded
Maximum update depth exceeded in App.svelte:3:1. This can happen when a reactive block or effect repeatedly sets a new value. Svelte limits the number of nested updates to prevent infinite loops

If there are multiple effects running in a loop, the message could be more like this...

Uncaught Svelte error: effect_update_depth_exceeded
Maximum update depth exceeded. This can happen when a reactive block or effect repeatedly sets a new value. Svelte limits the number of nested updates to prevent infinite loops. Last ten effects:

App.svelte:3:1
App.svelte:10:1
App.svelte:3:1
App.svelte:10:1
App.svelte:3:1
App.svelte:10:1
App.svelte:3:1
App.svelte:10:1
App.svelte:3:1
App.svelte:10:1

...or we could try and be smarter about it so that we identify the actual loop (which aside from truly pathological cases should just be a case of going back until we see the most recent effect earlier in the stack?)

Importance

nice to have

[dummdidumm]

The reason I went with the functions itself is that you get a link to the function location "for free", and it is correctly pointing to the source; either what you wrote (via sourcemaps) or what was generated (if sourcemaps are turned off) (which is still useful). Using the stack trace isn't gonna work because for that to be transformed into clickable links correctly you need the generated code location (file + position) info, and at the time when we apply the location information we only have the original code.

[Rich-Harris]

There's several places where we emit ${filename}:${line}:${column} in error and warning messages already, where it wouldn't make sense to print a function (because we're pointing to an element or an attribute or whatever) — I think there's value in consistency, especially since finding the clickable link involves clicking through a bunch of junk

[dummdidumm]

From discord: it would be useful to get the same for the "cannot mutate state inside a derived" error

[trueadm]

Moving this to 5.x as it's non blocking.

[Azarattum]

It would be really useful for debugging to be able to inspect the effect trace manually. Similar to how we can inspect the stack trace with console.trace. Btw, it would be fine as a dev mode only feature.

[KieranP]

This would be extremely helpful. Evidently there is an undocumented breakage in Svelte 5, because our Svelte 4 component files, which worked in Svelte 4, now fail on Svelte 5. We are getting tons of the effect_update_depth_exceeded errors in our tests, but currently no way to know exactly where they are coming from, making migration very difficult. So I would very much welcome some sort of ${filename}:${line}:${column} indication.

[paoloricciuti]

This would be extremely helpful. Evidently there is an undocumented breakage in Svelte 5, because our Svelte 4 component files, which worked in Svelte 4, now fail on Svelte 5. We are getting tons of the effect_update_depth_exceeded errors in our tests, but currently no way to know exactly where they are coming from, making migration very difficult. So I would very much welcome some sort of ${filename}:${line}:${column} indication.

Did you migrate to rune too? Because svelte 5 should be pretty much back compatible with 4 especially the labeled statement shouldn't produce infinite loops. Can you provide a reproduction?

[KieranP]

@paoloricciuti No, these errors appear to be in non-rune svelte files. And I'd happily produce a reproduction, but without the error mentioning where it is happening, I don't know which of the 400 odd svelte files I have is causing it ^_^ Once Svelte is able to report the error location, I will file a new ticket highlighting the Svelte 4 syntax causing the infinite loops.