mirror of https://github.com/astral-sh/ruff
7d3b7c5754
In https://github.com/astral-sh/ruff/pull/21957, we tried to use `union_or_intersection_elements_ordering` to provide a stable ordering of the union and intersection elements that are created when determining which type a typevar should specialize to. @AlexWaygood [pointed out](https://github.com/astral-sh/ruff/pull/21551#discussion_r2616543762) that this won't work, since that provides a consistent ordering within a single process run, but does not provide a stable ordering across runs. This is an attempt to produce a proper stable ordering for constraint sets, so that we end up with consistent diagnostic and test output. We do this by maintaining a new `source_order` field on each interior BDD node, which records when that node's constraint was added to the set. Several of the BDD operators (`and`, `or`, etc) now have `_with_offset` variants, which update each `source_order` in the rhs to be larger than any of the `source_order`s in the lhs. This is what causes that field to be in line with (a) when you add each constraint to the set, and (b) the order of the parameters you provide to `and`, `or`, etc. Then we sort by that new field before constructing the union/intersection types when creating a specialization. |
||
|---|---|---|
| .. | ||
| resources | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| build.rs | ||
| mdtest.py | ||
| mdtest.py.lock | ||