move constructors from `TyCtxt` to the constructed types

[lcnr]

Proposal

a new proposal for the idea in https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Add.20.60TyCtxt.60.20wrappers.20to.20sort.20its.20methods.E2.80.A6.20compiler-team.23603/near/343950786. supersedes #603

Currently most constructors which rely on interning are methods on TyCtxt. This causes a few issues:

• it is inconsistent, as only some of them are on TyCtxt while others are defined on the constructed type itself:e .g. TraitRef::identity and TraitRef::from_method vs TyCtxt::mk_trait_ref. Constructors for types which are not directly interned tend to also be MyType::new, e.g. Obligation::new.
• it is often unclear how to construct stuff as you cannot find the constructor in the documentation of the types itself, especially if you don't already know that you have to often use the TyCtxt.
• the docs for TyCtxt are incredibly large so methods on it tend to be difficult to discover

Because of this we should move constructors, i.e. methods currently called TyCtxt::mk_X, to the types itself, renaming them to X::new. For mk_some_variant_of_X we should rename them to X::new_variant_name, e.g. Type::new_bound. These methods should take the TyCtxt as the first argument.

For types in rustc_type_ir which need a TyCtxt to be constructed we can make the constructor generic over Interner:

// imagine we moved `Ty` into `rustc_type_ir`
struct Ty<I: Interner> {
    fields: ...,
}

impl<I: Interner> Ty<I> {
    // Avoid this in favour of more specific `new_*` methods, where possible.
    #[allow(rustc::usage_of_ty_tykind)]
    #[inline]
    pub fn new_ty_from_kind(tcx: I, st: TyKind<'tcx>) -> Ty<'tcx> {
          tcx.intern_ty(...) // or something like that, just add the ability to intern a `Ty` to the `Interner` trait
    }

    pub fn new_bound(tcx: I, index: DebruijnIndex, bound_ty: BoundTy) -> Ty<I> {
        Self::new_from_kind(Bound(index, bound_ty
    }
}

Mentors or Reviewers

I may be able to review some of this though I would prefer someone else taking this over. We can make it an E-easy issue for new contributors.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[pnkfelix]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted