ruff/crates/ty_python_semantic/resources
Douglas Creager c3de8847d5
[ty] Consider domain of BDD when checking whether always satisfiable (#21050)
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.
2025-10-24 13:37:56 -04:00
..
corpus [ty] fix deferred name loading in PEP695 generic classes/functions (#19888) 2025-08-13 15:51:59 -07:00
mdtest [ty] Consider domain of BDD when checking whether always satisfiable (#21050) 2025-10-24 13:37:56 -04:00
primer [ty] Add cycle handling to lazy_default (#20967) 2025-10-23 10:05:08 +02:00
README.md

Markdown files within the mdtest/ subdirectory are tests of type inference and type checking; executed by the tests/mdtest.rs integration test.

See crates/ty_test/README.md for documentation of this test format.