Add a way to add constructors for `rustc_type_ir` types #121703

compiler-errors · 2024-02-27T20:25:42Z

Introduces a module called rustc_type_ir, in which we can place traits which are named Ty/Region/Const/etc. which expose constructors for the rustc_type_ir types. This means we can construct things Interner::Ty with Ty::new_x(...), which is needed to uplift the new trait solver into an interner-agnostic crate.

These traits are placed into a separate module because they're only intended to be used in interner-agnostic code, and they should mirror the constructors that are provided by the inherent constructor methods in rustc_middle.

Putting this up for vibe-check mostly. I haven't copied over any of the type constructors, except for one to create bound types for use in the canonicalizer.

r? lcnr

compiler-errors · 2024-02-27T20:27:00Z

compiler/rustc_type_ir/src/new.rs

@@ -0,0 +1,19 @@
+use crate::{BoundVar, ConstKind, DebruijnIndex, Interner, RegionKind, TyKind};
+
+pub trait Ty<I: Interner<Ty = Self>> {


I don't believe it's feasible to share code b/w this and rustc_middle, since I expect we don't want to import this Ty trait into hundreds and hundreds of modules in the compiler, and also this would conflict with the naming of Ty in rustc_middle.

This naming conflict is actually kind of intentional, since we can use Ty::new_x(...) in uplifted solver code without really needing to change much.

time to figure out how to create custom preludes 🙃

The duplication seems fine, though it would be neat if we could generate most of the boilerplate

lcnr

I think it's a good approach 👍

I think longterm we may want to lobby for some sort of #[treat_as_inherent_for_lookup] when implementing traits for types in their local crate to remove the duplication. But at least for now this seems like it's probably the best we can do

lcnr · 2024-02-29T15:12:12Z

compiler/rustc_middle/src/ty/sty.rs

+    fn new(tcx: TyCtxt<'tcx>, kind: ty::TyKind<'tcx>) -> Self {
+        Ty::new(tcx, kind)
+    }


why is that method needed on the trait?

Can be used for default impls later on, perhaps. I expect implementations won't need to fill all of the constructors, but just provide the ones that cant be impl'd generically. Could remove until that point tho.

please do, I think statically preventing the solver from using new is disirable

lcnr · 2024-02-29T15:13:38Z

compiler/rustc_type_ir/src/new.rs

+}
+
+pub trait Region<I: Interner<Region = Self>> {
+    fn new(interner: I, kind: RegionKind<I>) -> Self;


same here, should never be used

lcnr · 2024-02-29T15:14:13Z

compiler/rustc_type_ir/src/new.rs

+}
+
+pub trait Const<I: Interner<Const = Self>> {
+    fn new(interner: I, kind: ConstKind<I>, ty: I::Ty) -> Self;


and here 😁

jackh726 · 2024-02-29T15:49:29Z

so...

is Ty::new_anon_bound(self.interner(), self.binder_index, var) really all that much better than self.interner().mk_bound_ty(self.binder_index, var)?

I also think that if we're going to go this route, we consider not essentially duplicating traits here, and have a single trait New like:

trait New<I: Interner> {
  type Out;
  type Data;
  fn new(interner: I, data: Self::Data) -> Self::Out;
}

trait Interner: Sized {
  type Ty: ... + New<Self, Out = Self::Ty, Data = TyKind<Self>>;
}

example

compiler-errors · 2024-02-29T15:53:42Z

[...] really all that much better [...]

Yes, I believe it's incentivized by the same reason we put all of the constructors onto Ty in the first place. I expect us to be adding most of the ty constructors -- for now, we only have placeholder.

we consider not essentially duplicating traits here, and have a single trait New like [...]

This is not compatible with the signature for Const constructors, which also take a type, and also won't work when we have various sprcialized constructors for various variants on ty/region/const.

jackh726 · 2024-02-29T16:02:05Z

Yes, I believe it's incentivized by the same reason we put all of the constructors onto Ty in the first place. I expect us to be adding most of the ty constructors -- for now, we only have placeholder.

The rustc_type_ir crate only really needs one function to create the interned type - I would expect the "core" solver code probably doesn't have a ton of places where we would need all the separate variants. Implementing crates can provide their own helper functions for the separate variants.

This is not compatible with the signature for Const constructors, which also take a type

It certainly is:

impl New<()> for Const {
    type Out = Const;
    type Data = (ConstKind<()>, Ty);
    fn new(interner: (), data: Self::Data) -> Self::Out { Ty }
}

and also won't work when we have various sprcialized constructors for various variants on ty/region/const.

you can modify the trait like this if it's really necessary:

trait New<I: Interner, Data> {
  type Out;
  fn new(interner: I, data: Data) -> Self::Out;
}

compiler-errors · 2024-02-29T16:27:54Z

The rustc_type_ir crate only really needs one function to create the interned type - I would expect the "core" solver code probably doesn't have a ton of places where we would need all the separate variants.

There are 23 matches for the regex (Ty|Const|Region)::new_ in the solver code (creating error variants, projections, adts, slices, and tuples). And an additional 9 matches to \.(types|lifetimes|consts)\. (unit ty and ReStatic) which will need to go through constructors as well.

Implementing crates can provide their own helper functions for the separate variants.

Why? This is just scattering code over more crates for what, a bit less code duplication?

you can modify the trait like this if it's really necessary:

This seems really obtuse. Also, I'd rather not have to construct my types with New::new() -- the type punning here with trait Ty being named identically to Ty is intentional, since it ensures that code reads similarly between compiler-internal code and the code being abstracted here (e.g. Ty::new_unit(tcx) and Ty::new_unit(self.interner())).

lcnr · 2024-03-04T16:36:35Z

given @jackh726 👍 above

@bors r+ rollup

bors · 2024-03-04T16:36:38Z

📌 Commit 1eedca8 has been approved by lcnr

It is now in the queue for this repository.

Add a way to add constructors for `rustc_type_ir` types Introduces a module called `rustc_type_ir`, in which we can place traits which are named `Ty`/`Region`/`Const`/etc. which expose constructors for the `rustc_type_ir` types. This means we can construct things `Interner::Ty` with `Ty::new_x(...)`, which is needed to uplift the new trait solver into an interner-agnostic crate. These traits are placed into a *separate* module because they're only intended to be used in interner-agnostic code, and they should mirror the constructors that are provided by the inherent constructor methods in `rustc_middle`. Putting this up for vibe-check mostly. I haven't copied over any of the type constructors, except for one to create bound types for use in the canonicalizer. r? lcnr

…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#120976 (constify a couple thread_local statics) - rust-lang#121683 (Fix LVI tests after frame pointers are enabled by default) - rust-lang#121703 (Add a way to add constructors for `rustc_type_ir` types) - rust-lang#121732 (Improve assert_matches! documentation) - rust-lang#121928 (Extract an arguments struct for `Builder::then_else_break`) - rust-lang#121939 (Small enhancement to description of From trait) - rust-lang#121968 (Don't run test_get_os_named_thread on win7) - rust-lang#121969 (`ParseSess` cleanups) - rust-lang#121977 (Doc: Fix incorrect reference to integer in Atomic{Ptr,Bool}::as_ptr.) - rust-lang#121994 (Update platform-support.md with supported musl version) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#121703 - compiler-errors:new, r=lcnr Add a way to add constructors for `rustc_type_ir` types Introduces a module called `rustc_type_ir`, in which we can place traits which are named `Ty`/`Region`/`Const`/etc. which expose constructors for the `rustc_type_ir` types. This means we can construct things `Interner::Ty` with `Ty::new_x(...)`, which is needed to uplift the new trait solver into an interner-agnostic crate. These traits are placed into a *separate* module because they're only intended to be used in interner-agnostic code, and they should mirror the constructors that are provided by the inherent constructor methods in `rustc_middle`. Putting this up for vibe-check mostly. I haven't copied over any of the type constructors, except for one to create bound types for use in the canonicalizer. r? lcnr

rustbot assigned lcnr Feb 27, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 27, 2024

compiler-errors commented Feb 27, 2024

View reviewed changes

compiler-errors changed the title ~~Allow a way to add constructors for rustc_type_ir types~~ Add a way to add constructors for rustc_type_ir types Feb 27, 2024

oli-obk approved these changes Feb 28, 2024

View reviewed changes

lcnr reviewed Feb 29, 2024

View reviewed changes

Allow a way to add constructors for rustc_type_ir types

1eedca8

rust-cloud-vms bot force-pushed the new branch from 04cff47 to 1eedca8 Compare March 4, 2024 15:42

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 4, 2024

This was referenced Mar 4, 2024

Rollup of 10 pull requests #121995

Closed

Rollup of 10 pull requests #121998

Merged

bors merged commit e7bb224 into rust-lang:master Mar 5, 2024

rustbot added this to the 1.78.0 milestone Mar 5, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add a way to add constructors for `rustc_type_ir` types #121703

Add a way to add constructors for `rustc_type_ir` types #121703

Uh oh!

compiler-errors commented Feb 27, 2024

Uh oh!

compiler-errors Feb 27, 2024

Uh oh!

oli-obk Feb 28, 2024

Uh oh!

lcnr left a comment

Uh oh!

lcnr Feb 29, 2024

Uh oh!

compiler-errors Feb 29, 2024

Uh oh!

lcnr Feb 29, 2024

Uh oh!

lcnr Feb 29, 2024

Uh oh!

lcnr Feb 29, 2024

Uh oh!

jackh726 commented Feb 29, 2024

Uh oh!

compiler-errors commented Feb 29, 2024

Uh oh!

jackh726 commented Feb 29, 2024

Uh oh!

compiler-errors commented Feb 29, 2024

Uh oh!

lcnr commented Mar 4, 2024

Uh oh!

bors commented Mar 4, 2024

Uh oh!

Uh oh!

		@@ -0,0 +1,19 @@
		use crate::{BoundVar, ConstKind, DebruijnIndex, Interner, RegionKind, TyKind};

		pub trait Ty<I: Interner<Ty = Self>> {

Add a way to add constructors for rustc_type_ir types #121703

Add a way to add constructors for rustc_type_ir types #121703

Uh oh!

Conversation

compiler-errors commented Feb 27, 2024

Uh oh!

compiler-errors Feb 27, 2024

Choose a reason for hiding this comment

Uh oh!

oli-obk Feb 28, 2024

Choose a reason for hiding this comment

Uh oh!

lcnr left a comment

Choose a reason for hiding this comment

Uh oh!

lcnr Feb 29, 2024

Choose a reason for hiding this comment

Uh oh!

compiler-errors Feb 29, 2024

Choose a reason for hiding this comment

Uh oh!

lcnr Feb 29, 2024

Choose a reason for hiding this comment

Uh oh!

lcnr Feb 29, 2024

Choose a reason for hiding this comment

Uh oh!

lcnr Feb 29, 2024

Choose a reason for hiding this comment

Uh oh!

jackh726 commented Feb 29, 2024

Uh oh!

compiler-errors commented Feb 29, 2024

Uh oh!

jackh726 commented Feb 29, 2024

Uh oh!

compiler-errors commented Feb 29, 2024

Uh oh!

lcnr commented Mar 4, 2024

Uh oh!

bors commented Mar 4, 2024

Uh oh!

Uh oh!

Add a way to add constructors for `rustc_type_ir` types #121703

Add a way to add constructors for `rustc_type_ir` types #121703