Provide an extended framework for type visit, for use in rust-analyzer #149856
+399
−55
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
rust-analyzer needs to be able to visit types when treating not only
Ty,Const,RegionandPredicatespecifically, but all rust-analyzer-made types specifically (excluding e.g.TraitRef, that is declared in rustc_type_ir). This is needed to implement garbage collection.To support this, we introduce a second, rust-analyzer-only visit trait, named, without much thought,
CustomizableTypeVisitable. It's simpler thanTypeVisitable(for example, it does not have a trait for the visitor, and does not support early-returning) because this is what rust-analyzer needs, but its most distinguished feature is that the visitor is a generic of the trait instead of the method. This way, specific types can treat specific visitor types specifically and call their methods.In rustc_type_ir we implement it for a bunch of basic types, and using a derive macro for the rest. The macro and trait are completely disabled when compiling for rustc (
feature = "nightly"), so not even a compile time penalty will be paid.r? types
This is a replacement to other efforts to support non-
Copytype in the solver, replacing them with a GC in r-a, as decided by @rust-lang/rust-analyzer. The code is tiny in comparison, and I believe T-types will have no problem maintaining it, which mostly means adding the derive on new things when they are added and things break on the r-a side.