[red-knot] Consolidate all gradual types into single Type variant

[dcreager]

Prompted by #15381 (comment):

One nit: I think we need to consider Any and Unknown and Todo as all (gradually) equivalent to each other, and thus type & Any and type & Unknown and type & Todo as also equivalent. The distinction between Any vs Unknown vs Todo is entirely about provenance/debugging, there is no type level distinction. (And I've been wondering if the Any vs Unknown distinction is really worth it.)

The thought here is that most places want to treat Any, Unknown, and Todo identically. So this PR simplifies things by having a single Type::Any variant, and moves the provenance part into a new AnyType type. If you need to treat e.g. Todo differently, you still can by pattern-matching into the AnyType. But if you don't, you can just use Type::Any(_).

(This would also allow us to (more easily) distinguish "unknown via an unannotated value" from "unknown because of a typing error" should we want to do that in the future)

[sharkdp]

I like it! (haven't reviewed each and every change, but I guess it's more or less mechanical)

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[AlexWaygood]

Brilliant idea! Is it possibly worth calling the variant and struct Type::Gradual and GradualType rather than Type::Any and AnyType? Type::Any(AnyType::Unknown) reads a bit strangely to me

[AlexWaygood]

Also: all roads lead to Rome

[dcreager]

Brilliant idea! Is it possibly worth calling the variant and struct Type::Gradual and GradualType rather than Type::Any and AnyType? Type::Any(AnyType::Unknown) reads a bit strangely to me

Done

[dcreager]

but I guess it's more or less mechanical

That is a good callout. I did try to make this a pure refactoring. For instance, there are a couple of places where we were doing something only for a Todo, but not for Any or Unknown. Instead of inspecting and possibly changing those in this PR, I've left them as-is so that this PR does not combine a refactoring with a logic change.

[dcreager]

e.g. here

[carljm]

This is excellent!!

[carljm]

This makes handling these in match statements so much nicer!

[carljm]

Side note on seeing this method, wondering why we need it, and going to look: I wonder if maybe we shouldn't allow Any/Unknown/Todo to coexist in the same union/intersection, and instead should just define a hierarchy of preference, e.g. Todo takes top priority, Any second, and Unknown third?

Definitely not something for this PR, just musing.