Several fixes to JS typing of functions and methods

[ahejlsberg]

In this PR:

• Properly compute SignatureFlagsIsUntypedSignatureInJSFile such that calls to untyped functions and methods declared in .js files allow arguments to be omitted.
• Limit @type JSDoc annotations to functions and methods (specifically, ignore @type annotations in constructors and accessors).
• Use full signature and parameter names from @type annotations (similar to Strada).
• Ensure export modifier is respected when @type annotations are present.

Fixes #1521.
Fixes #1957.

[Copilot]

Pull Request Overview

This PR fixes several issues related to JavaScript function and method typing. The main changes ensure that untyped functions/methods in .js files correctly allow arguments to be omitted, and that @type JSDoc annotations are properly applied with full signature information including parameter names and optionality.

Key changes:

• Properly computes SignatureFlagsIsUntypedSignatureInJSFile so untyped JS functions/methods treat all parameters as optional
• Restricts @type JSDoc annotations to only apply to functions and methods (excluding constructors and accessors)
• Uses full signature information from @type annotations including parameter names and optionality markers

Reviewed Changes

Copilot reviewed 40 out of 40 changed files in this pull request and generated 1 comment.

File	Description
internal/checker/checker.go	Computes untyped signature flag for JS files; restricts @type application to appropriate function types
internal/checker/emitresolver.go	Ensures JSDoc-declared signatures aren't treated as overload implementations
internal/ast/utilities.go	Exports IsMethodOrAccessor function for external use
testdata/baselines/reference/*	Updated test baselines reflecting corrected behavior for untyped JS functions and @type annotations

Comments suppressed due to low confidence (1)

internal/checker/checker.go:1

• [nitpick] This multi-line boolean expression could be split into smaller named boolean variables to improve readability. For example, isJSFunctionLike, hasNoTypedParameters, and hasNoContextualSignature would make the logic clearer.

package checker

[Copilot]

The condition declaration.Flags&ast.NodeFlagsJSDoc == 0 checks if the JSDoc flag is NOT set, but there's no comment explaining why JSDoc-flagged declarations should be excluded from being considered overload implementations. Adding a brief comment would clarify this non-obvious logic.

Suggested change

	declaration := signaturesOfSymbol[0].declaration
	declaration := signaturesOfSymbol[0].declaration
	// JSDoc signatures are not considered overloads, so exclude JSDoc-flagged declarations.

[jakebailey]

Curious loss of error; it's maybe fine but I would have expected this to still error given this is contextually typed by the declarations?

[ahejlsberg]

This looks to be an issue with reparsing. In Corsa, we currently consider the @type annotation to only apply to the variable declaration and not the arrow function. In Strada we consider the annotation to apply to both. I'll look at fixing this, provided we like the Strada approach.

[jakebailey]

I feel like this is something @sandersn changed but I can't remember anymore.

If it's a big change I don't think it's a big deal to ignore for this PR either.

[ahejlsberg]

And, I should add, in Corsa, because the @type annotation doesn't apply to the arrow function, the arrow function is considered completely untyped and therefore gets the SignatureFlagsIsUntypedSignatureInJSFile flag and the more permissive arity check.

[ahejlsberg]

And, I should further add, the arrow function is considered completely untyped because the contextual type doesn't have an applicable signature. That's a bit too aggressive, so with the latest commit, any contextual type for a function in a .js file causes us to not consider that function untyped.