This fixes a small regression introduced in #15050. Prior to that PR, we would handle memoization in different ways throughout the compiler; now, the memoization logic is more explicit and consistent. The decision of whether to memoize happens inside build_attribute_value (or build_template_chunk), using the passed-in logic — if an expression contains a CallExpression, we memoize — but this elides an important distinction between component props and other expressions.

In most cases, an expression like a + b doesn't get memoized (it doesn't contain a CallExpression). But for component props, we do memoize these expressions, because otherwise we get overfiring in a case like this:

<Foo active={i === index} />

The result, post-#15050, is that anything containing a CallExpression gets memoized twice — once because it's contains a CallExpression, and once because it's a 'non-simple' expression (i.e. not an Identifier or MemberExpression).

The result is that we create two deriveds where one will do — a case like this...

<script>
  let { fn } = $props();
</script>

<Foo bar={fn()} />

...has this outcome:

-var bar = $.derived(() => $$props.fn());
+const expression = $.derived(() => $$props.fn());
+var bar = $.derived(() => $.get(expression));

Foo($$anchor, {
  get bar() {
    return $.get(bar);
  }
});

This PR fixes it by taking the decision of whether to memoize out of build_attribute_value and build_template_chunk and into their callers.

It also makes the memoization of spreads-with-call-expressions consistent with other template effects:

var div = root();
-const spread_with_call = $.derived(() => $$props.foo($$props.a, $$props.b));
let attributes;

-$.template_effect(() => attributes = $.set_attributes(div, attributes, { ...$.get(spread_with_call) }));
+$.template_effect(($0) => attributes = $.set_attributes(div, attributes, { ...$0 }), [() => $$props.foo($$props.a, $$props.b)]);

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