refactor types to fit the chalk-ty generic plan #341
Labels
major-change
A proposal to make a major change to rustc
major-change-accepted
A major change proposal that was accepted
T-compiler
Add this label so rfcbot knows to poll the compiler team
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, whereI
is the 'interner', and aTyData
orTyKind
enum that contains the variants (name to be settled). A methoddata()
orkind()
will be used to go from one to the other. rustc already has a separation much like this, in the form of theTy<'tcx>
andTyKind<'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::Ty
is the generic definition from this shared library.TyCtxt<'tcx>
would play the role of the interner.This MCP proposes the first few step towards that goal, which I think are simply
ty.kind
toty.kind()
, which isfn kind(&self) -> &TyKind
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 wantedImplications. 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 sometimesmatch *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>
implementsDeref
to some type with a field namedkind
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:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.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.
The text was updated successfully, but these errors were encountered: