Allow functions to be printed structurally in declaration emit even when they have symbols#21203
Allow functions to be printed structurally in declaration emit even when they have symbols#21203weswigham merged 2 commits intomicrosoft:mastermicrosoft/TypeScript:masterfrom weswigham:allow-structural-function-outputweswigham/TypeScript:allow-structural-function-outputCopy head branch name to clipboard
Conversation
…hen they have symbols
| if (symbol.flags & SymbolFlags.Class && !getBaseTypeVariableOfClass(symbol) && !(symbol.valueDeclaration.kind === SyntaxKind.ClassExpression && context.flags & NodeBuilderFlags.WriteClassExpressionAsTypeLiteral) || | ||
| symbol.flags & (SymbolFlags.Enum | SymbolFlags.ValueModule) || | ||
| shouldWriteTypeOfFunctionSymbol()) { | ||
| shouldWriteTypeOfFunctionSymbol() && !(context.flags & NodeBuilderFlags.UseStructuralFallback && isSymbolAccessible(symbol, context.enclosingDeclaration, SymbolFlags.Value, /*computeAliases*/ false).accessibility !== SymbolAccessibility.Accessible)) { |
There was a problem hiding this comment.
A helper similar to isTypeSymbolAccessible would be nice to avoid writing .accessibility !== SymbolAccessibility.Accessible.
Also, why not just put the && part inside of shouldWriteTypeOfFunctionSymbol?
There was a problem hiding this comment.
Good point. I'll move it into shouldWriteTypeOfFunctionSymbol.
| else { | ||
| errorNameNode = declaration.name; | ||
| const format = TypeFormatFlags.UseTypeOfFunction | TypeFormatFlags.WriteDefaultSymbolWithoutName | | ||
| const format = TypeFormatFlags.UseTypeOfFunction | TypeFormatFlags.UseStructuralFallback | TypeFormatFlags.WriteDefaultSymbolWithoutName | |
There was a problem hiding this comment.
It looks like we're using TypeFormatFlags.UseStructuralFallback in all the same places we already use TypeFormatFlags.UseTypeOfFunction. Can they be combined?
There was a problem hiding this comment.
They could be, but then external consumers lose the choice of allowing the structural fallback or not. I'm erring on the side of being more configurable here, since they are seperate behaviors. This way allows something like a quickfix to try to build a node using typeof with no fallback, see if there's an error, then decide not to offer the fix, for example.
#18860 introduced a break in a few of our RWC tests (mobx, one more) when it swapped to aggressively using
typeoffor the reproduction of function types (in order to be more like the type baseline output), but never introduced a fallback to the structural version of the type if the type wasn't accessible for declaration emit. This adds that fallback (and a flag to control it).