Skip to content

Conversation

@weswigham
Copy link
Member

@weswigham weswigham commented Apr 10, 2018

In #23280 @Andy-MS brought up that we never preserve aliases used to create inferred types (which makes sense, given that we immediately collapse type aliases down to their target types). With this PR, we preserve and clone return types of signatures (and thereby their aliases) provided they still yield the same type in the new context. This won't solve the issue in the OP of #23280 (as the alias is annotated within the function body and not as the signature return type node itself), but does make @Andy-MS's simplified example work as one may hope.

I'm not 100% sold on this always being a good thing (checkout the type baselines for all the places where any became a copy of the erroneous declaration that generated any), but it does produce nice results in many places (including preserving input style).

@weswigham weswigham changed the title Clone signature return type nodes if they are present and yield the same type Clone signature return type nodes if they are present and yield the same type as the signature return type Apr 10, 2018
@weswigham weswigham requested review from a user, mhegazy and rbuckton April 10, 2018 00:15
@rbuckton
Copy link
Contributor

@weswigham can you look at the failing test in the build?

}

function isEntityNameVisible(entityName: EntityNameOrEntityNameExpression, enclosingDeclaration: Node): SymbolVisibilityResult {
function resolveNameFromEntityName(entityName: EntityNameOrEntityNameExpression, enclosingDeclaration: Node) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we already have a resolveEntityName function?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This skips a lot of the work resolveEntityName does to verify namespaceyness and also generates an appropriate meaning from the entityName's parent. So they're a bit different, unfortunately.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We either should have only one function with options to control behavior (preferred), or should clearly document the difference between the two.

function getDeepSynthesizedCloneAndPaintVisibility<T extends Node>(node: T | undefined): T | undefined {
if (isEntityName(node) || isEntityNameExpression(node)) {
// Paint visible aliases required for copied nodes (so required imports are not elided)
isEntityNameVisible(node, context.enclosingDeclaration);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling isEntityNameVisible without using the result is odd. I understand what this is doing, but perhaps its better to split isEntityNameVisible into two functions: one that tracks visibility and one that uses the result.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That'd just be hasVisibleDeclarations(resolveNameFromEntityName(entityName, enclosingDeclaration), /*shouldComputeAliasToMakeVisible*/ true), I suppose?

@typescript-bot
Copy link
Collaborator

Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it.

@microsoft microsoft locked as resolved and limited conversation to collaborators Oct 21, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants