-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[ty] Sort collected diagnostics before snapshotting them in mdtest #17926
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
Thank you! I noticed this a couple of times and I was going to open an issue for it. |
|
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.
Nice, thank you
crates/ruff_db/src/diagnostic/mod.rs
Outdated
/// Returns a key that can be used to sort two diagnostics into the canonical order | ||
/// in which they should appear when rendered. | ||
pub fn rendering_sort_key<'a, 'db>(&'a self, db: &'db dyn Db) -> impl Ord + 'a | ||
where | ||
'db: 'a, | ||
{ | ||
RenderingSortKey { | ||
db, | ||
diagnostic: self, | ||
} | ||
} |
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.
Nit: I sort of like how TextRange
solved this. It has a ordering
method. It could help reduce some complexity (no need for an extra struct, less lifetimes)
pub fn ordering(&self, db: &dyn Db, other: &Self) -> Ordering {
if let (Some(span1), Some(span2)) = (
self.primary_span(),
other.primary_span(),
) {
let order = span1
.file()
.path(self.db)
.as_str()
.cmp(span2.file().path(self.db).as_str());
if order.is_ne() {
return order;
}
if let (Some(range1), Some(range2)) = (span1.range(), span2.range()) {
let order = range1.start().cmp(&range2.start());
if order.is_ne() {
return order;
}
}
}
// Reverse so that, e.g., Fatal sorts before Info.
let order = self
.severity()
.cmp(&other.severity())
.reverse();
if order.is_ne() {
return order;
}
self.id().cmp(&other.id())
}
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 realised I could simplify it to a single lifetime (pushed the change). I weakly prefer encapsulating the sorting logic into a struct that represents the key (the way I have it now), but no strong opinion; happy to revisit this in a followup if others agree!
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 don't feel too strongly personally. I'm fine with either approach given that these aren't semver boundaries.
…lass * origin/main: [`pylint`] add fix safety section (`PLC2801`) (#17825) Add instructions on how to upgrade to a newer Rust version (#17928) [parser] Flag single unparenthesized generator expr with trailing comma in arguments. (#17893) [ty] Ensure that `T` is disjoint from `~T` even when `T` is a TypeVar (#17922) [ty] Sort collected diagnostics before snapshotting them in mdtest (#17926) [ty] Add basic file watching to server (#17912) Make completions an opt-in LSP feature (#17921) Add link to `ty` issue tracker (#17924) [ty] Add support for `__all__` (#17856) [ty] fix assigning a typevar to a union with itself (#17910) [ty] Improve UX for `[duplicate-base]` diagnostics (#17914) Clean up some Ruff references in the ty server (#17920)
Summary
ty's diagnostics are always sorted into a stable order when ty is executed on the command line. However, this sorting is not applied when the diagnostics are collected by mdtests, which can result in them being snapshotted in our tests in a different order than they would appear to users. That's quite confusing.
This PR fixes that by sorting the diagnostics collected by mdtest in the same way that we sort them when
ty
is actually executed on the command line.Test Plan
cargo test -p ty_python_semantic
cargo test -p ty_project