-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fixAddMissingMember: Support interface and don't crash on type parameter #25995
Conversation
} | ||
return res; | ||
} | ||
|
||
type ClassOrInterface = ClassLikeDeclaration | InterfaceDeclaration; | ||
interface InfoBase { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the way the Info types are broken down. Why isn't there a separate InfoKind
for interface? Is that uninteresting? What's the advantage of having a base type if the members are redeclared in the subtypes? Is there an advantage/disadvantage compared to just unioning the two subtypes? Why does EnumInfo
have fewer fields?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see that Info
is declared as a union type. Why does InfoBase
exist at all then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having fewer cases in a union is better since each union type needs its own code to handle. EnumInfo
has fewer fields because the code handling it is a completely separate path that does different things from the ClassOrInterfaceInfo
case. That's necessary because enums work much differently than classes/interfaces, but for class/interface the handling is mostly the same and it's better to just test isInterfaceDeclaration
when necessary.
interface InfoBase { | ||
readonly kind: InfoKind; | ||
readonly token: Identifier; | ||
readonly parentDeclaration: EnumDeclaration | ClassLikeDeclaration; | ||
readonly parentDeclaration: EnumDeclaration | ClassOrInterface; | ||
} | ||
enum InfoKind { enum, class } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you really need this enum since you can do this check through parentDeclaration.kind ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That currently wouldn't work to discriminate the union. See #18758.
1270cac
to
c3e765d
Compare
c3e765d
to
3166ef3
Compare
@amcasey @sheetalkamat Please re-review |
* origin/master: (283 commits) Don't error on destructure of private property with computed property syntax (microsoft#26360) getDefaultExportInfo: Use `getImmediateAliasedSymbol` instead of `getAliasedSymbol` (microsoft#26364) review comments restore old algorithm Dont use baseURL relative absolute paths in declaration emit, use absolute paths in bundle emit (microsoft#26341) Update user baselines (microsoft#26358) Don't store @template constraint in a TypeParameterDeclaration node (microsoft#26283) fixAddMissingMember: Support interface and don't crash on type parameter (microsoft#25995) Don't include class getter in spread type (microsoft#26287) Don't crash on computed property in destructure (microsoft#26334) Check the ambientness of a symbol name before attempting to trim it (microsoft#26312) Still generate signatures in SkipContextSensitive mode just to match on return types (microsoft#25937) fix handling if there is no commonPrefix Actually add sorting of elaboration text to user baselines Ping ryan instead of mohammed for user PRs now handle failed lookups make it work for root directory really, really fix test(?) add test fix commonPrefix handling ...
Fixes #25725