Skip to content

lint/tidy check imports of rustc_type_ir and rustc_middle #138449

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
lcnr opened this issue Mar 13, 2025 · 3 comments
Open

lint/tidy check imports of rustc_type_ir and rustc_middle #138449

lcnr opened this issue Mar 13, 2025 · 3 comments
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-help-wanted Call for participation: Help is requested to fix this issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@lcnr
Copy link
Contributor

lcnr commented Mar 13, 2025

rustc_middle reexports all of rustc_type_ir and should be preferred in case it is available. We should lint if a crate depends on both rustc_middle and rustc_type_ir and rewrite all existing uses of rustc_type_ir in such crates to use rustc_middle::ty instead.

cc @compiler-errors
@lcnr lcnr added C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-help-wanted Call for participation: Help is requested to fix this issue. labels Mar 13, 2025
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 13, 2025
@compiler-errors compiler-errors mentioned this issue Mar 13, 2025
Merged
@jieyouxu jieyouxu added A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Mar 14, 2025
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 14, 2025
@bors
Auto merge of rust-lang#138464 - compiler-errors:less-type-ir, r=lcnr
6fbc082 
Use `rustc_type_ir` directly less in the codebase

cc rust-lang#138449

This is a somewhat opinionated bundle of changes that will make working on rust-lang#138449 more easy, since it cuts out the bulk of the changes that would be necessitated by the lint. Namely:

1. Fold `rustc_middle::ty::fold` and `rustc_middle::ty::visit` into `rustc_middle::ty`. This is because we already reexport some parts of these modules into `rustc_middle::ty`, and there's really no benefit from namespacing away the rest of these modules's functionality given how important folding and visiting is to the type layer.
2. Rename `{Decodable,Encodable}_Generic` to `{Decodable,Encodable}_NoContext`[^why], change it to be "perfect derive" (`synstructure::AddBounds::Fields`), use it throughout `rustc_type_ir` instead of `TyEncodable`/`TyDecodable`.
3. Make `TyEncodable` and `TyDecodable` derives use `::rustc_middle::ty::codec::TyEncoder` (etc) for its generated paths, and move the `rustc_type_ir::codec` module back to `rustc_middle::ty::codec` :tada:.
4. Stop using `rustc_type_ir` in crates that aren't "fundamental" to the type system, namely middle/infer/trait-selection. This amounted mostly to changing imports from `use rustc_type_ir::...` to `use rustc_middle::ty::...`, but also this means that we can't glob import `TyKind::*` since the reexport into `rustc_middle::ty::TyKind` is a type alias. Instead, use the prefixed variants like `ty::Str` everywhere -- IMO this is a good change, since it makes it more regularized with most of the rest of the compiler.

[^why]: `_NoContext` is the name for derive macros with no additional generic bounds and which do "perfect derive" by generating bounds based on field types. See `HashStable_NoContext`.

I'm happy to cut out some of these changes into separate PRs to make landing it a bit easier, though I don't expect to have much trouble with bitrot.

r? lcnr
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 15, 2025
@bors
Auto merge of rust-lang#138464 - compiler-errors:less-type-ir, r=lcnr
aa95b96 
Use `rustc_type_ir` directly less in the codebase

cc rust-lang#138449

This is a somewhat opinionated bundle of changes that will make working on rust-lang#138449 more easy, since it cuts out the bulk of the changes that would be necessitated by the lint. Namely:

1. Fold `rustc_middle::ty::fold` and `rustc_middle::ty::visit` into `rustc_middle::ty`. This is because we already reexport some parts of these modules into `rustc_middle::ty`, and there's really no benefit from namespacing away the rest of these modules's functionality given how important folding and visiting is to the type layer.
2. Rename `{Decodable,Encodable}_Generic` to `{Decodable,Encodable}_NoContext`[^why], change it to be "perfect derive" (`synstructure::AddBounds::Fields`), use it throughout `rustc_type_ir` instead of `TyEncodable`/`TyDecodable`.
3. Make `TyEncodable` and `TyDecodable` derives use `::rustc_middle::ty::codec::TyEncoder` (etc) for its generated paths, and move the `rustc_type_ir::codec` module back to `rustc_middle::ty::codec` :tada:.
4. Stop using `rustc_type_ir` in crates that aren't "fundamental" to the type system, namely middle/infer/trait-selection. This amounted mostly to changing imports from `use rustc_type_ir::...` to `use rustc_middle::ty::...`, but also this means that we can't glob import `TyKind::*` since the reexport into `rustc_middle::ty::TyKind` is a type alias. Instead, use the prefixed variants like `ty::Str` everywhere -- IMO this is a good change, since it makes it more regularized with most of the rest of the compiler.

[^why]: `_NoContext` is the name for derive macros with no additional generic bounds and which do "perfect derive" by generating bounds based on field types. See `HashStable_NoContext`.

I'm happy to cut out some of these changes into separate PRs to make landing it a bit easier, though I don't expect to have much trouble with bitrot.

r? lcnr
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Mar 16, 2025
@bors
Auto merge of #138464 - compiler-errors:less-type-ir, r=lcnr
7bae54a 
Use `rustc_type_ir` directly less in the codebase

cc rust-lang/rust#138449

This is a somewhat opinionated bundle of changes that will make working on rust-lang/rust#138449 more easy, since it cuts out the bulk of the changes that would be necessitated by the lint. Namely:

1. Fold `rustc_middle::ty::fold` and `rustc_middle::ty::visit` into `rustc_middle::ty`. This is because we already reexport some parts of these modules into `rustc_middle::ty`, and there's really no benefit from namespacing away the rest of these modules's functionality given how important folding and visiting is to the type layer.
2. Rename `{Decodable,Encodable}_Generic` to `{Decodable,Encodable}_NoContext`[^why], change it to be "perfect derive" (`synstructure::AddBounds::Fields`), use it throughout `rustc_type_ir` instead of `TyEncodable`/`TyDecodable`.
3. Make `TyEncodable` and `TyDecodable` derives use `::rustc_middle::ty::codec::TyEncoder` (etc) for its generated paths, and move the `rustc_type_ir::codec` module back to `rustc_middle::ty::codec` :tada:.
4. Stop using `rustc_type_ir` in crates that aren't "fundamental" to the type system, namely middle/infer/trait-selection. This amounted mostly to changing imports from `use rustc_type_ir::...` to `use rustc_middle::ty::...`, but also this means that we can't glob import `TyKind::*` since the reexport into `rustc_middle::ty::TyKind` is a type alias. Instead, use the prefixed variants like `ty::Str` everywhere -- IMO this is a good change, since it makes it more regularized with most of the rest of the compiler.

[^why]: `_NoContext` is the name for derive macros with no additional generic bounds and which do "perfect derive" by generating bounds based on field types. See `HashStable_NoContext`.

I'm happy to cut out some of these changes into separate PRs to make landing it a bit easier, though I don't expect to have much trouble with bitrot.

r? lcnr
@lcnr lcnr mentioned this issue Mar 19, 2025
Merged
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue Mar 20, 2025
@bors
Auto merge of #138464 - compiler-errors:less-type-ir, r=lcnr
f357993 
Use `rustc_type_ir` directly less in the codebase

cc rust-lang/rust#138449

This is a somewhat opinionated bundle of changes that will make working on rust-lang/rust#138449 more easy, since it cuts out the bulk of the changes that would be necessitated by the lint. Namely:

1. Fold `rustc_middle::ty::fold` and `rustc_middle::ty::visit` into `rustc_middle::ty`. This is because we already reexport some parts of these modules into `rustc_middle::ty`, and there's really no benefit from namespacing away the rest of these modules's functionality given how important folding and visiting is to the type layer.
2. Rename `{Decodable,Encodable}_Generic` to `{Decodable,Encodable}_NoContext`[^why], change it to be "perfect derive" (`synstructure::AddBounds::Fields`), use it throughout `rustc_type_ir` instead of `TyEncodable`/`TyDecodable`.
3. Make `TyEncodable` and `TyDecodable` derives use `::rustc_middle::ty::codec::TyEncoder` (etc) for its generated paths, and move the `rustc_type_ir::codec` module back to `rustc_middle::ty::codec` :tada:.
4. Stop using `rustc_type_ir` in crates that aren't "fundamental" to the type system, namely middle/infer/trait-selection. This amounted mostly to changing imports from `use rustc_type_ir::...` to `use rustc_middle::ty::...`, but also this means that we can't glob import `TyKind::*` since the reexport into `rustc_middle::ty::TyKind` is a type alias. Instead, use the prefixed variants like `ty::Str` everywhere -- IMO this is a good change, since it makes it more regularized with most of the rest of the compiler.

[^why]: `_NoContext` is the name for derive macros with no additional generic bounds and which do "perfect derive" by generating bounds based on field types. See `HashStable_NoContext`.

I'm happy to cut out some of these changes into separate PRs to make landing it a bit easier, though I don't expect to have much trouble with bitrot.

r? lcnr
@rperier rperier mentioned this issue Apr 30, 2025
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 30, 2025
@matthiaskrgr
Rollup merge of rust-lang#140516 - rperier:type-ir-to-type-middle, r=…
1e440ae 
…lcnr

Replace use of rustc_type_ir by rustc_middle

cc rust-lang#138449

I want to help on this issue. I have replaced all the rustc_type_ir uses by the equivalent type in rustc_middle.
DelayedSet is also re-exposed by rustc_middle.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 30, 2025
@rust-timer
Unrolled build for rust-lang#140516
3935773 
Rollup merge of rust-lang#140516 - rperier:type-ir-to-type-middle, r=lcnr

Replace use of rustc_type_ir by rustc_middle

cc rust-lang#138449

I want to help on this issue. I have replaced all the rustc_type_ir uses by the equivalent type in rustc_middle.
DelayedSet is also re-exposed by rustc_middle.
@rperier rperier mentioned this issue May 1, 2025
Merged
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 5, 2025
@GuillaumeGomez
Rollup merge of rust-lang#140559 - rperier:type-ir-to-type-middle, r=…
f403c92 
…compiler-errors

Removing rustc_type_ir in the rustc_infer codebase

cc rust-lang#138449

This is a second refactoring of rustc_type_ir to use rustc_middle instead, this time that's for rustc_infer
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 5, 2025
@GuillaumeGomez
Rollup merge of rust-lang#140559 - rperier:type-ir-to-type-middle, r=…
224e3ca 
…compiler-errors

Removing rustc_type_ir in the rustc_infer codebase

cc rust-lang#138449

This is a second refactoring of rustc_type_ir to use rustc_middle instead, this time that's for rustc_infer
rust-timer added a commit to rust-lang-ci/rust that referenced this issue May 6, 2025
@rust-timer
Unrolled build for rust-lang#140559
bacfbd4 
Rollup merge of rust-lang#140559 - rperier:type-ir-to-type-middle, r=compiler-errors

Removing rustc_type_ir in the rustc_infer codebase

cc rust-lang#138449

This is a second refactoring of rustc_type_ir to use rustc_middle instead, this time that's for rustc_infer
@rperier
Copy link
Contributor

rperier commented May 21, 2025 •
edited
Loading

Hi,

I think I need a bit of help for adding the lint,

  • Adding a new LateLintPass should do the trick for this lint, I think
  • we could add a diagnostic item for each type in type_ir that is not supposed to be used from rustc_type_ir (but from rustc_middle instead)

My problem: In order to detect that a crate use both rustc_middle and rustc_type_ir I will probably need to "tag" conflicting types with diagnostic items and check for these from the lint. However, diagnostic items are usually only added to traits, types, and standalone functions... and not on re-exported types right ? I mean, we do not have these types or trait definition in rustc_middle, as we re-export these.

@lcnr
Copy link
Contributor Author

lcnr commented May 21, 2025 •
edited
Loading

I would expect that all direct uses of rustc_type_ir should emit a lint in the source. We can then explicitly allow the lint in the rustc_next_trait_solver crate and the desirable uses in middle and for SolverDelegate + InferCtxtLike impls.

We could special-case rustc_next_trait_solver in the lint/detect crates which only depend on rustc_type_ir. I feel like doing so may not be worth it, given that we can just add a single #![allow(direct_use_of_rustc_type_ir)] or whatever

@rperier
Copy link
Contributor

rperier commented May 21, 2025 •
edited
Loading

That's indeed simpler, I got it. I prefer using #![allow(direct_use_of_rustc_type_ir)] , that's what is done by the rustc::usage_of_type_ir_traits lint for the rustc_next_trait_solver crate.

@rperier rperier mentioned this issue May 26, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-help-wanted Call for participation: Help is requested to fix this issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rperier @lcnr @jieyouxu @rustbot