Description
Proposal
In March of 2020, we had a design meeting about the idea to create a shared library for types, specifically one that could be used for chalk, rust-analyzer, and rustc alike. This is part of a process that aims to allow us to extract trait/type-checking into distinct crates that can be reused in multiple contexts. In particular we would like chalk to be integrated into rustc without having to do any "translation" between the different representations of types.
As described in the design meeting, the expectation is that this shared library will consist of a separation between a Ty<I> wrapper type, where I is the 'interner', and a TyData or TyKind enum that contains the variants (name to be settled). A method data() or kind() will be used to go from one to the other. rustc already has a separation much like this, in the form of the Ty<'tcx> and TyKind<'tcx> types, but to match this description fully, these types would change somewhat:
Ty<'tcx>would eventually be an alias forty::Ty<TyCtxt<'tcx>>, wherety::Tyis the generic definition from this shared library.- As you can see, the
TyCtxt<'tcx>would play the role of the interner.
This MCP proposes the first few step towards that goal, which I think are simply
- change from
ty.kindtoty.kind(), which isfn kind(&self) -> &TyKind - change from
ty.kind()toty.kind(tcx)-- in chalk, accessing the kind requires the interner, which permits types that use integers instead of interned pointers, but we could skip this step if we wanted - other minor changes of this kind
Implications. There is a prototype PR in rust-lang/rust#75077 that works through some of the implications. One point to note is that match ty.kind() { .. .} produces references for the fields within, which is often not what we want, because those fields are copy, and thus sometimes match *ty.kind() { .. } is preferable (though, as you can see in rust-lang/rust#75077, not always.
Alternatives. It occurs to me that the shared type library could be setup such that Ty<I> implements Deref to some type with a field named kind for some interners, i.e., those that implement an auxiliary trait, thus avoiding the need to make this change -- we would still want to make this change for each library that aims to be reused in multiple contexts, but for rustc-specific code it wouldn't be necessary.
Not included in this MCP
This MCP does NOT include reorganizing the variants of types. In chalk, we have a much more minimal set of variants. I do think we should reorganize the rustc variants but I think it'd be a good idea to discuss those steps separately.
Mentors or Reviewers
@nikomatsakis can mentor to the extent it is needed
@LeSeulArtichaut started doing the implementation work
Process
The main points of the Major Change Process is 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 mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a
- 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.