Conversation
| @@ -4520,7 +4523,7 @@ namespace ts { | |||
| const noTruncation = compilerOptions.noErrorTruncation || flags & TypeFormatFlags.NoTruncation; | |||
| const typeNode = nodeBuilder.typeToTypeNode(type, enclosingDeclaration, toNodeBuilderFlags(flags) | NodeBuilderFlags.IgnoreErrors | (noTruncation ? NodeBuilderFlags.NoTruncation : 0), writer); | |||
| if (typeNode === undefined) return Debug.fail("should always get typenode"); | |||
| const options = { removeComments: true }; | |||
| const options = { removeComments: type !== unresolvedType }; | |||
There was a problem hiding this comment.
Would be helpful to leave a comment on this one (pun intended).
| const options = { removeComments: type !== unresolvedType }; | |
| // The unresolved type gets a synthesized comment on `any` | |
| // to hint to users that it's not a plain `any`. | |
| // Otherwise, we always strip comments out. | |
| const options = { removeComments: type !== unresolvedType }; |
There was a problem hiding this comment.
Sure, I'll add a comment.
src/compiler/checker.ts Outdated
| @@ -8255,6 +8269,10 @@ namespace ts { | |||
| return type && (type.flags & TypeFlags.Any) !== 0; | |||
| } | |||
| function isErrorType(type: Type) { | |||
| return type === errorType || !!(type.flags & TypeFlags.Any && type.aliasSymbol); | |||
There was a problem hiding this comment.
Why not just this? Seems like it'd be cheaper too.
| return type === errorType || !!(type.flags & TypeFlags.Any && type.aliasSymbol); | |
| return type === errorType || type === unresolvedType; |
There was a problem hiding this comment.
No, that wouldn't work. I'll add a clarifying comment, but basically we want to identify the special TypeFlags.Any types produced by getTypeForTypeAliasReference for an unresolved symbol. The sole purpose of unresolvedType is to act as the declared type for the special type alias symbols we create for unresolved names. The type is never actually returned by anything because getTypeForTypeAliasReference maps it into a special TypeFlags.Any type with an aliasSymbol.
| @@ -4,6 +4,6 @@ async function foo(): Promise<void> { | |||
| // Legal to use 'await' in a type context. | |||
| var v: await; | |||
| >v : any | |||
| >v : await | |||
There was a problem hiding this comment.
Is there some way to make the type writer a little smarter here so that the team can differentiate between an unresolved and a concrete type?
There was a problem hiding this comment.
We certainly have the ability to tell the difference, but what did you have in mind in terms of output? Remember that we're often dealing with composed types, e.g. for var v: Promise<await[]> we can't easily attach a comment to the await identifier in the output.
There was a problem hiding this comment.
A parenthesized type might work like (/*unresolved*/ await)
There was a problem hiding this comment.
I'm not really sure we want to do that. We're already generate an error at every reference to an unresolved symbol, I don't think we also want the extra noise in the type baselines.
I guess this doesn't technically fix #38836 because this only applies to types, right? |
Right, this doesn't fix #38836. One complication there would be what scope to introduce the unknown value symbols into. Should they be locals of the innermost enclosing function, or just globals like we do for the type symbols? The latter typically makes sense for types, but less clear for unresolved value symbols. |
I think just a global scope makes enough sense; if you do have a bunch of unresolved variables spread throughout your codebase, it's convenient to find-all-references, and likely to be a global anyhow; if it's mostly local (e.g. a user forgot to locally declare it), it doesn't really matter where you put it. But I'd understand if we wanted to take it one step at a time. |
Looks like there's a few conflicts that need to be resolved. |
# Conflicts: # src/compiler/checker.ts # tests/cases/fourslash/findReferencesJSXTagName.ts # tests/cases/fourslash/tsxFindAllReferences10.ts
With this PR we create type aliases for unresolved symbols such that quick info and error messages list back the unresolved name instead of just
any.In this example where
ItemDatais not defined:hovering over
itemanditemsnow showsItemDataandItemData[]where previously we'd just showanyandany[]. Furthermore, hovering over the unresolvedItemDatareference showstype ItemData = /*unresolved*/ any.Fixes #45893.