Start using pattern types in libcore

[oli-obk]

cc #135996

blocked on rust-analyzer getting support for computing the right layout for pattern types

cc @Veykril no rush here, as long as we can't replace NonNull, there's no point in doing this change just yet

[compiler-errors]

Well r=me when/if it does get unblocked.

[scottmcm]

Unsure: at least for the NonZeroBlahInner ones, it'd be nicer if these could just be type $name = pattern_type!($int is $low..=$high);, without the extra wrapper. Is that feasible, or are the trait implementations too far off?

(Relatedly, I'd love to be able to just derive traits on these again, particularly to not have to manually StructuralPartialEq.)

[oli-obk]

Yea... I wanna get there, but directly using pattern types is not a great experience at present

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[Veykril]

Re rust-analyzer blocker, as it turns out to implement pattern types (to a degree that would unblock this) it comes down to the same architecture changes required as for rust-lang/rust-analyzer#7434 (which I am currently looking into), so that will take a bit.

[rustbot]

Some changes occurred to the CTFE machinery

cc @rust-lang/wg-const-eval

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

[Veykril]

Re rust-analyzer blocker, as it turns out to implement pattern types (to a degree that would unblock this) it comes down to the same architecture changes required as for rust-lang/rust-analyzer#7434 (which I am currently looking into), so that will take a bit.

@Veykril I think for the most part you could just treat pattern types opaquely and ignore the pattern's details. Casts to the base type don't require looking at the pattern and instantiating pattern types from literals could just be ignored by r-a and left to rustc. I don't think you actually need the layout of pattern types for anything else

But isn't the point of them that they have niches? If we treat them opaquely we won't see the niches of the type for layout calculation.

Either way I should be unblocked regarding rust-lang/rust-analyzer#7434 so I can start working on that again starting next week. Though if you want to get this merged and r-a is the remaining blocking reason we can work around it by special casing the relevant std/core type(s) if needed I think

[oli-obk]

But isn't the point of them that they have niches? If we treat them opaquely we won't see the niches of the type for layout calculation.

Ah then the sizes shown by ra would be wrong. Hmm I've never seem the sizes, didn't think about that

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[bors]

☔ The latest upstream changes (presumably #138464) made this pull request unmergeable. Please resolve the merge conflicts.

[Veykril]

Btw, the implementation block has been lifted in r-a. (that is the pre-requisite work for rust-lang/rust-analyzer#7434). But since we still use chalk's IR we can't represent pattern types in the type system yet, so that's still kind of blocked there.