fix(1374): support declaration emit for expando functions

[a-tarasyuk]

Fixes #1374

[jakebailey]

It's interesting that this temp variable turns into _b and not _a; it's not incorrect but I wonder if something isn't being cleared between expandos or something.

(I am reading this on my phone so have not actually read the code yet)

[jakebailey]

Maybe not for this PR but I wonder what the leftover code difference is that's adding "declare" to these.

[weswigham]

This looks like a pretty straight port of the logic from strada - @sandersn should weigh in on weather he thinks that's right. I do not recall if these is one of the constructs that changed meaningfully in the js reparser rewrite and, thus, should also have it's declaration emit logic adjusted, too.

[sandersn]

Expandos didn't fundamentally change, but they are losing a lot of their complicated features. So the core changes to emit might be right-ish, but you won't need to reintroduce any code in the parser or binder, I think.

[a-tarasyuk]

@sandersn Thanks for the clarification.

[sandersn]

the binder already has to detect these patterns, so you shouldn't need to port anything new.

edit: your explanation of why these are needed makes sense, but much of it can be simplified given how much less Corsa supports.

[sandersn]

expando declarations should only be binary expressions now.

/** @type {string} */
f.p

is no longer supported by Corsa, and access expressions don't have a Symbol field.

[sandersn]

prototype assignments aren't supported in Corsa
(C.prototype = { ... })

[sandersn]

defaulting assignments with x.p = x.p || function() {} are not supported in Corsa.

[jakebailey]

This needs a merge from main again since one of the baselines changed via another PR.

[a-tarasyuk]

@jakebailey Thanks for pointing it out. I’ve merged main

[jakebailey]

It's super odd that the original code did not emit a declaration file here, not sure why (the new code looks correct).

[weswigham]

This is still pretty semantic in how it operates - the binder is much more syntactic now, and I think we can be more syntactic in the declaration emitter now, too, because of it. Specifically, I'd like to avoid needing a GetPropertiesOfContainerFunction emit resolver function. I'd rather we visited expression statements, looking for assignment expressions that are expando assignments (ast.GetAssignmentDeclarationKind result of Property - I think the js reparser even sets a .Type on these now!), and translate them to the equivalent expansion, instead of seeing the function declaration and semantically checking for extra properties to patch on. So, for example, we see the AST for

export function foo() { return 1 }
/** @type {"ok"} */
foo.bar = "ok"

we visit export function foo() { return 1 } and emit export function foo(): number and then we visit

/** @type {"ok"} */
foo.bar = "ok"

and emit

export namespace foo { export const bar: "ok" }

Notably, multiple expandos would emit as multiple namespaces:

export namespace foo { export const bar: "ok" }
export namespace foo { export const baz: "yes" }

by default, and then you can have a "collection" pass at the end of a scope that merges all the newly added namespaces together (or into an explicit one, if it's there and the names all work out). The only awkward thing I can see here is that the export modifier-ness of the namespace declaration relies on nonlocal information (if the host function is exported). This could be alleviated by never exporting a function with expando properties (which is still a nonlocal semantic check, unfortunately...) via an export modifier, and instead adding a export { foo } declaration - then all the declarations can always be non-exported (which is roughly how the old js declaration emitter in the node builder would have done it, and then had an extra pass to "inline" the export declarations as modifiers where possible).

[a-tarasyuk]

@weswigham, thanks for the feedback. I've started implementing this approach and ran into a few edge cases that are worth considering:

1. Default exports. When a function with expandos is a default export:

export default function foo() {}
foo.meta = 123;

We can't emit:

export default function foo(): void;
export namespace foo { export const meta: 123; }

As part of this, I’ve added a temporary solution using pendingDefaultExport, which defers the default export until after all expandos are emitted. However, this slightly changes the behavior for export default function declarations without expandos — they're now emitted in split form rather than as a single default-exported function.

2. Non-exported hosts

For:

function foo() {}
foo.extra = true;

We cannot emit:

export namespace foo { const extra: true; }

At this stage, it's necessary to determine whether the host is exported, to correctly apply or omit the export modifier from the merged namespace declaration

3. Type resolution scope

To correctly serialize the type of an expando property and avoid self-references,

declare namespace Example {
    const Bar: typeof Bar;
}

The type resolver typically relies on the enclosingDeclaration to determine symbol visibility and to avoid self-references during serialization. This means that information about the surrounding namespace scope should be available and correctly set during type serialization to ensure accurate and consistent type output.

@weswigham WDYT?