fix: suppress TS4055/TS4073 for protected methods using typeof parameter

[umeshmore45]

Fixes #61591

Problem

Protected methods in exported classes incorrectly raised TS4055/TS4073
when using typeof parameter in return type or parameter type, even
though the same pattern works correctly for public methods and standalone
functions.

Fix

In src/compiler/transformers/declarations/diagnostics.ts, added a
protected check in getReturnTypeVisibilityError and
getMethodNameVisibilityDiagnosticMessage. When a method is protected,
we return undefined (no error) instead of raising TS4055/TS4073.

Tests

• Added tests/cases/compiler/protectedMethodTypeofParameter.ts
• All 106368 tests passing

[umeshmore45]

@microsoft-github-policy-service agree

[Copilot]

Pull request overview

Adjusts declaration-emit symbol accessibility diagnostics to avoid incorrectly reporting TS4055/TS4073 for protected methods that use typeof <parameter> in types.

Changes:

• Adds protected checks in declaration diagnostics to return undefined (suppress) for certain method-related visibility diagnostics.
• Adds a new compiler test case protectedMethodTypeofParameter.ts plus baselines to cover the protected return-type typeof parameter scenario.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/cases/compiler/protectedMethodTypeofParameter.ts	New repro covering protected method return type using typeof parameter under --declaration.
tests/baselines/reference/protectedMethodTypeofParameter.types	Baseline for types output of the new test.
tests/baselines/reference/protectedMethodTypeofParameter.symbols	Baseline for symbols output of the new test.
tests/baselines/reference/protectedMethodTypeofParameter.js	Baseline including emitted JS + generated .d.ts for the new test.
src/compiler/transformers/declarations/diagnostics.ts	Suppresses some symbol accessibility diagnostics when a class method is protected.

Comments suppressed due to low confidence (1)

src/compiler/transformers/declarations/diagnostics.ts:401

• This change only suppresses TS4055-like return-type visibility diagnostics for protected methods. The TS4073 case from the issue (parameter type using Properties[typeof propertyName] on a protected method) is still handled via getParameterDeclarationTypeVisibilityDiagnosticMessage, which has no protected handling, so the parameter-type false-positive likely remains. Please add the corresponding fix for parameter visibility diagnostics (or, preferably, fix the underlying typeof parameter accessibility logic so both return/parameter cases are handled consistently).

                    if (hasEffectiveModifier(node, ModifierFlags.Protected)) {
                        return undefined;
                    }
                    diagnosticMessage = symbolAccessibilityResult.errorModuleName ?
                        symbolAccessibilityResult.accessibility === SymbolAccessibility.CannotBeNamed ?
                            Diagnostics.Return_type_of_public_method_from_exported_class_has_or_is_using_name_0_from_external_module_1_but_cannot_be_named :
                            Diagnostics.Return_type_of_public_method_from_exported_class_has_or_is_using_name_0_from_private_module_1 :
                        Diagnostics.Return_type_of_public_method_from_exported_class_has_or_is_using_private_name_0;

---

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

Returning undefined for all protected methods here disables declaration-emit visibility checks for their return types entirely. That fixes the typeof parameter false-positive, but it also allows protected methods to reference truly non-exported types (e.g. protected m(): PrivateType) without error, which would emit an invalid .d.ts that refers to an unnameable symbol. A safer fix would be to keep visibility checking for protected methods and instead special-case typeof <parameter> so the referenced parameter symbol is treated as in-scope/accessible.

Suggested change

	if (hasEffectiveModifier(node, ModifierFlags.Protected)) {
	return undefined;
	}

[Copilot]

The new test covers the protected-method return type case, but it doesn't cover the TS4073 scenario from the issue where another parameter’s type references typeof propertyName (e.g. propertyValue: Properties[typeof propertyName]). Adding that protected setter-style method (and asserting the .d.ts contains it without diagnostics) would prevent regressions and ensure the PR actually fixes both TS4055 and TS4073.

[Copilot]

The new protected early-return here suppresses all symbol accessibility diagnostics for protected methods with dynamic/computed names (this callback is only used from checkName when hasDynamicName(...) is true). That seems unrelated to the reported TS4055/TS4073 typeof parameter issue and may hide real declaration-emit errors for protected computed names that reference non-exported/private symbols. Consider removing this change, or limiting any suppression to the specific typeof parameter scenario instead of blanket-skipping protected methods.

Suggested change

	if (hasEffectiveModifier(node, ModifierFlags.Protected)) {
	return undefined;
	}