refactor: Made Kind an inherent part of DiagnosticEntry.#9301
Closed
orizi wants to merge 1 commit intoorizi/12-23-added_validation_of_error_code_not_being_duplicatedfrom
Conversation
|
This change is |
Collaborator
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Dec 23, 2025
TomerStarkware
approved these changes
Dec 23, 2025
Collaborator
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 6 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @orizi).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Refactored the
DiagnosticEntrytrait to use an associated typeKindfor diagnostic kinds instead of theis_same_kindmethod. This change improves type safety by enforcing that diagnostic kinds are compared with the same type, rather than relying on a custom comparison method.Why is this change needed?
The current implementation uses an
is_same_kindmethod to compare diagnostic entries, which requires manual implementation for each diagnostic type. This approach is error-prone and less type-safe. By using an associated type for the diagnostic kind, we leverage the type system to ensure that comparisons are done correctly, while also simplifying the code.What was the behavior or documentation before?
Previously, each diagnostic implementation had to provide an
is_same_kindmethod that manually compared diagnostic kinds. This required boilerplate code in each implementation and could lead to bugs if not implemented correctly.What is the behavior or documentation after?
Now, diagnostic entries have an associated
Kindtype that represents the kind of diagnostic. Equality comparison is done directly on these kinds using the standard==operator, which is more type-safe and requires less code. The implementation is also more consistent across different diagnostic types.Additional context
This change is part of ongoing efforts to improve the type safety and maintainability of the diagnostic system. It removes redundant code while making the comparison of diagnostic kinds more robust.