Describe the bug
Svelte's scope tracker reuses the same scope for a function's arguments and body. Body declarations end up referenced in argument initializers shadowing the parent scopes' declarations, potentially making an initializer skip rune transformation logic.
I tried fixing this a few different ways, but I couldn't find a clean way to deal with this due to my lack of familiarity with the v5 codebase (hi, everyone, miss you!). My thinking was to create two separate scopes, one for arguments and one for the body (either through the body's BlockStatement or the *Function* themselves), and perhaps call add_state_transformers on the function visitors, but every variation I tried ended up interacting badly with different compilation pipeline assumptions.
Turns out I just forgot to make the BlockStatement scope non-porous as opposed to the function's. Not sure this is the "cleanest" solution, but BlockStatement already had special-casing for the function cases. See attached PR.
Reproduction
Scope confusion causes runes' objects to be used instead of its values: https://svelte.dev/playground/590c171f1436486e9072bbc2641c9b53?version=5.53.3
Without required transformations, Svelte's incorrect assumption doesn't affect actual output: https://svelte.dev/playground/20b746af78ca4336b0a47c9e60aed1ec?version=5.53.3
Logs
System Info
Severity
annoyance
Describe the bug
Svelte's scope tracker reuses the same scope for a function's arguments and body. Body declarations end up referenced in argument initializers shadowing the parent scopes' declarations, potentially making an initializer skip rune transformation logic.
I tried fixing this a few different ways, but I couldn't find a clean way to deal with this due to my lack of familiarity with the v5 codebase (hi, everyone, miss you!). My thinking was to create two separate scopes, one for arguments and one for the body (either through the body'sBlockStatementor the*Function*themselves), and perhaps calladd_state_transformerson the function visitors, but every variation I tried ended up interacting badly with different compilation pipeline assumptions.Turns out I just forgot to make the
BlockStatementscope non-porous as opposed to the function's. Not sure this is the "cleanest" solution, butBlockStatementalready had special-casing for the function cases. See attached PR.Reproduction
Scope confusion causes runes' objects to be used instead of its values: https://svelte.dev/playground/590c171f1436486e9072bbc2641c9b53?version=5.53.3
Without required transformations, Svelte's incorrect assumption doesn't affect actual output: https://svelte.dev/playground/20b746af78ca4336b0a47c9e60aed1ec?version=5.53.3
Logs
System Info
Severity
annoyance