Pattern types: Avoid having to handle an Option for range ends in the type system or the HIR

[oli-obk]

Instead,

1. during hir_ty_lowering, we now generate constants for the min/max when the range doesn't have a start/end specified.
2. in a later commit we generate those constants during ast lowering, simplifying everything further by not having to handle the range end inclusivity anymore in the type system (and thus avoiding any issues of 0..5 being different from 0..=4

I think it makes all the type system code simpler, and the cost of the extra ConstKind::Value processing seems negligible.

r? @BoxyUwU

cc @joshtriplett @scottmcm

[rustbot]

changes to the core type system

cc @compiler-errors, @lcnr

changes to the core type system

cc @compiler-errors, @lcnr

HIR ty lowering was modified

cc @fmease

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[BoxyUwU]

Something I was thinking about when reviewing this was whether this "normalization" of patterns to always be inclusive w/ both ends specified is something that can be done even when we start to support patterns such as N..M.

One thing that definitely wont be supported is continuing to lower to an anon const of the form { <T as RangePattern>::sub_one(...) } as generic parameters in anon consts work very poorly. I think, there are ~three ways that we can make it work eventually though:

1. Wait for generic_const_expressions to be redesigned in terms of an extension to min_generic_const_args. From there we can make sub_one an associated constant. Something like <T as Trait<N>>::SUB_ONE. If we have a where clause on that assoc const that requires lower < N (required for lower..N to be a valid pattern type) then we can ensure ctfe won't kill the compilation session when evaluating <u32 as Trait<N>>::SUB_ONE.
2. Hack up our hir/ty::Const repr to have a builtin version of SUB_ONE. Some kind of hir::ConstArgKind::SubOne/ty::ConstKind::Expr(ExprKind::SubOne. We can make type system normalization special case normalization of ExprKind::SubOne to check the value is >0 and then if it is just subtract one 🤷‍♀️ Eventually this can likely be replaced with a gce based hack once that exists
3. Introduce some kind of UnboundedInt type with no upper/lower bound on what integers it can store. This would allow addition and subtraction to be a pure function that always terminates. We could then make range patterns of integers use such a type so that u8 is -1..40000 is a valid type.

Implying the right where clauses such that 2..=N-1 and 2..N are both able to be proven wf is maybe a bit tricky but I expect to be very doable. I also think that having to deal with optionally open ended and inclusive vs exclusive ranges in the type system is likely to be rather annoying so this is refactor is pretty important 🤔

[BoxyUwU]

@bors r+

[bors]

📌 Commit 73b7e5f has been approved by BoxyUwU

It is now in the queue for this repository.