Pattern types MVP

[oli-obk]

Doing #107299 the right way ™️

cc @joshtriplett for the language side

This PR adds pattern types to the parser and a minimal version to the type system. This isn't useful yet, as you can't create values of pattern types type except via transmute, but I thought it best to land this MVP and then iterate on the feature instead of producing a bigger and bigger PR that becomes harder to review with every addition.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jackh726 (or someone else) soon.

Please see the contribution instructions for more information.

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

rustdoc-json-types is a public (although nightly-only) API. If possible, consider changing src/librustdoc/json/conversions.rs; otherwise, make sure you bump the FORMAT_VERSION constant.

cc @CraftSpider, @aDotInTheVoid, @Enselic, @obi1kenobi

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[RalfJung]

My confusion about this error message remains.^^ Who's asking for a pattern to be computed from anything here? We just want a variant count! What does it even mean to compute a pattern from a pattern? Seems trivial, just use the identity function...

[compiler-errors]

doesn't this change the behavior of macro code like:

macro_rules! foo {
  ($ty:ty) => {};
  (() is $pat:pat) => {};
}

foo!(() is 0..1);

[Noratrieb]

macro rules matches continue being the least forwards compatible thing ever :|

[compiler-errors]

Maybe it's better to expose this through a builtin macro instead of surface syntax, like rustc_pattern_type!() which expands into ast::TyKind::Pat

[fmease]

Or builtin#Pat(…) instead of a built-in macro (with builtin# from T-compiler MCP #580).

[estebank]

macro rules matches continue being the least forwards compatible thing ever :|

And this is where the editions system can shine.

[CAD97]

... I'm a little surprised/sad that foo! works at all today. Follow sets and greedy parsing were supposed to handle this -- you're not allowed to follow a :ty fragment with is -- but follow set restrictions are only applied within an arm, and not across arms. Being able to follow a fragment with some token in a simultaneously-taken arm matching the fragment's tokens essentially makes follow sets ineffectual at their job of making fragments forwards compatible. But simultaneously, applying follow set rules between arms would be very restrictive and probably not even solve the problem entirely, since you can attack non-follow-set grammar extensions similarly. I guess you'd need to ensure that the choice of which arm to take is always known to be forwards-compatibly LL(k) via some sort of "leading set," and if the choice isn't LL(k), ensure that the refining match fits within the grammar and follow set of the refined fragment.

i.e., complicated. And still overly restrictive, since we also have the rule for lexically prior arms taking priority over latter arms, so there's only a forwards compatibility concern if the refining arms come after the refined arm. (And until today I thought that macro parsing was greedier than it actually is, preventing foo! from ever matching the second arm here, since the $:ty arm is prior and matched the prefix. Despite probably relying on that not being the case.)

[calebcartwright]

cc @rust-lang/style

This seems quite reasonable and noncontroversial to me, and I'd be surprised if there's any vehement objections to this formatting. However, want to make sure everyone has seen it in case we'd like a chance to discuss this as a team first.

In the event we do want to review as a team to identify and codify the formatting rules, then this can be changed to re-emit the original input contents in the interim via something like:

Suggested change

	ast::TyKind::Pat(ref ty, ref pat) => {
	let ty = ty.rewrite(context, shape)?;
	let pat = pat.rewrite(context, shape)?;
	Some(format!("{ty} is {pat}"))
	},
	ast::TyKind::Pat(..) => Some(context.snippet(self.span).to_owned()),

[fbstj]

Suggested change

	hir_analysis_pattern_type_wild_pat = "wildcard patterns are not permitted for pattern types"
	.label = "this type is the same as the inner type without a pattern"
	hir_analysis_pattern_type_non_const_range = "range patterns must have constant range start and end"
	hir_analysis_pattern_type_wild_pat = wildcard patterns are not permitted for pattern types
	.label = this type is the same as the inner type without a pattern
	hir_analysis_pattern_type_non_const_range = range patterns must have constant range start and end

[scottmcm]

Not asking for it to be implemented in this PR, but is the idea that these will have subtyping or coercions to less-restrictive patterns? Is u8 the same as u8 is 0..=255?

I think I'm in favour, but it'd be nice to have a link to a post or something about a sketch of the goal here.

[joboet]

What if types with patterns didn't have niches on their own, but were subtypes of the unbounded type? This would solve construction and usage:

Construction is accomplished by matching the unbounded type against the pattern:

match value as i32 {
    x @ 0.. => Some(x), // x has type `i32 is 0..`
    _ => None,
}

Since i32 is 0.. is a subtype of i32, this is backwards compatible.

Only if the pattern type is explicitly used in a field does the niche get exposed:

struct NonZeroI32(i32 is ..0 | 1..);

println!("{}", size_of::<Option<NonZeroI32>>()); // Prints "4"
println!("{}", size_of::<Option<i32 is ..0 | 1..>>(); // Prints "5"

Since the field is not generic, the subtyping information is hidden, so having a niche is sound. #[repr(transparent)] would hide the niche again.

[Maix0]

I am currently fiddling with rustc as a first project to implement way to make subenum (only at the declaration of the enum tho). This is kinda the same thing but with a broader range.

I was thinking of allowing a sort of "specialization" where you can override function that exists in the parent enum. it would allow for some optimization.

If I understand correctly these "pattern restricted types" are just for type checking and the layout right ?
For the rest of rustc they are the parent type.

Would it be possible to add this functionnality to this or not (I doubt it since in my approch the subenums are declared WITH the main enum, and no consumer can create new subenum, so no orphan rule applies).

[tgross35]

Just some drive by prior art - this somewhat reminds me of ada pre & post conditions¹, which I've thought was a cool feature that could potentially fit in where clauses. Basically it just adds a runtime check (or compile time) for the arguments and for the function results, and panics if it's not true (for things like train/plane control systems and other high-SIL applications)

function Area(C: Circle)
   with Pre => C.X_Coord – C.Radius > 0.0,
        Post => Area'Result > 3.1 * C.Radius**2 and
                Area'Result < 3.2 * C.Radius**2;

Of course this is really more like the type constraints²³ that Ada also has, but just a bit of an interesting related note.

Footnotes

1. http://www.ada-auth.org/standards/12rat/html/Rat12-2-3.html ↩

2. https://docs.actian.com/ingres/10s/index.html#page/EmbedSQL/Type_Constraints.htm ↩

3. http://archive.adaic.com/standards/83rat/html/ratl-04-04.html ↩

[SoniEx2]

this does support #[non_exhaustive] yes?

[tialaramex]

I wrote "Where do I pick up a shovel and help?" four months ago. There has been no answer in the intervening period.

[oli-obk]

There's related discussion in https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/Implementing.20Enum.20Variant.20Types/near/322878006 (TLDR: someone is working on reviving this PR with a placeholder macro for syntax (to eliminate the parser/macro issues this PR has).

I don't know what the status of that work is, but maybe you two can collaborate?

[lcnr]

please open a types team MCP before trying to merge anything in this area (even if unstable). The exact way this new type kind should work is non-trivial and may have complex interactions with the rest of the type system.

[oli-obk]

Apropos, keeping this PR open serves no purpose :D I'm closing it, we can continue the discussion on zulip