-
Notifications
You must be signed in to change notification settings - Fork 640
Improve logic for choosing value/type meanings in quick info #867
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
Conversation
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.
Pull Request Overview
This PR improves the logic for choosing value/type meanings in quick info so that the correct meanings are displayed when hovering over identifiers.
- Updated the condition to check if the node is part of a type node or a type declaration name.
- Changed the flag clearing to remove variable and function flags when in a type context.
// If the symbol has a type meaning and we're not in an expression context, remove any value meanings | ||
flags &^= ast.SymbolFlagsValue | ||
if flags&ast.SymbolFlagsType != 0 && (ast.IsPartOfTypeNode(node) || isTypeDeclarationName(node)) { | ||
// If the symbol has a type meaning and we're in a type context, remove value-only meanings |
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.
[nitpick] The updated condition clarifies when a node is in a type context, but consider adding a comment explaining why 'isTypeDeclarationName' is checked here to improve code clarity.
// If the symbol has a type meaning and we're in a type context, remove value-only meanings | |
// If the symbol has a type meaning and we're in a type context, remove value-only meanings. | |
// The `isTypeDeclarationName` function checks if the node represents a name in a type declaration, | |
// ensuring that type-related flags are preserved while excluding value-only flags. |
Copilot uses AI. Check for mistakes.
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.
These nitpick comments are getting awful
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.
Indeed!
// If the symbol has a type meaning and we're not in an expression context, remove any value meanings | ||
flags &^= ast.SymbolFlagsValue | ||
if flags&ast.SymbolFlagsType != 0 && (ast.IsPartOfTypeNode(node) || isTypeDeclarationName(node)) { | ||
// If the symbol has a type meaning and we're in a type context, remove value-only meanings |
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.
[nitpick] The change from clearing all value flags to only clearing variable and function flags may be intentional; adding a clarifying comment on why other value flags are preserved would enhance maintainability.
// If the symbol has a type meaning and we're in a type context, remove value-only meanings | |
// If the symbol has a type meaning and we're in a type context, remove value-only meanings | |
// Specifically, clear the Variable and Function flags to avoid treating the symbol as a value. | |
// Other value flags are preserved intentionally to retain their specific meanings in this context. |
Copilot uses AI. Check for mistakes.
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.
IIRC Strada has a lot of logic for this but this seems reasonable
This PR fixes logic for choosing value/type meanings in quick info that wasn't quite working correctly. We now show the right meaning when hovering on each of the identifiers in this code: