mirror of
https://github.com/astral-sh/ruff.git
synced 2025-11-03 05:13:00 +00:00
c3de8847d5
That PR title might be a bit inscrutable. Consider the two constraints `T ≤ bool` and `T ≤ int`. Since `bool ≤ int`, by transitivity `T ≤ bool` implies `T ≤ int`. (Every type that is a subtype of `bool` is necessarily also a subtype of `int`.) That means that `T ≤ bool ∧ T ≰ int` is an impossible combination of constraints, and is therefore not a valid input to any BDD. We say that that assignment is not in the _domain_ of the BDD. The implication `T ≤ bool → T ≤ int` can be rewritten as `T ≰ bool ∨ T ≤ int`. (That's the definition of implication.) If we construct that constraint set in an mdtest, we should get a constraint set that is always satisfiable. Previously, that constraint set would correctly _display_ as `always`, but a `static_assert` on it would fail. The underlying cause is that our `is_always_satisfied` method would only test if the BDD was the `AlwaysTrue` terminal node. `T ≰ bool ∨ T ≤ int` does not simplify that far, because we purposefully keep around those constraints in the BDD structure so that it's easier to compare against other BDDs that reference those constraints. To fix this, we need a more nuanced definition of "always satisfied". Instead of evaluating to `true` for _every_ input, we only need it to evaluate to `true` for every _valid_ input — that is, every input in its domain. |
||
|---|---|---|
| .. | ||
| resources | ||
| src | ||
| tests | ||
| build.rs | ||
| Cargo.toml | ||
| mdtest.py | ||
| mdtest.py.lock | ||