lint direct use of rustc_type_ir

[rperier]

cc #138449

As previously discussed with @lcnr, it is a lint to prevent direct use of rustc_type_ir, except for some internal crates (like next_trait_solver or rustc_middle for example).

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[compiler-errors]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rperier]

@compiler-errors : Do I keep the existing lints for usage_of_type_ir_inherent and usage_of_type_ir_traits ? Or do I remove these, as they will implicitly be part of the lint "direct_use_of_rustc_type_ir" ? I mean the purpose of this new lint is to prevent the use of all types/traits under rustc_type_ir in random crates, including rustc_type_ir::inherent and rustc_type_ir::Interner , so we would have "one lint to rule them all" :p .

Also, diagnostic items seem to be only usable on exported modules, not the crate directly. So I gonna to add a diagnostic item on each public module exported by rustc_type_ir.

[compiler-errors]

Also, diagnostic items seem to be only usable on exported modules, not the crate directly. So I gonna to add a diagnostic item on each public module exported by rustc_type_ir.

Please don't do this. You should be able to put a #![diagnostic_item] attr on the crate. If that doesn't work, then we need to fix the diagnostic item implementation.

Do I keep the existing lints for usage_of_type_ir_inherent and usage_of_type_ir_traits ? Or do I remove these, as they will implicitly be part of the lint "direct_use_of_rustc_type_ir" ?

Yes, you should keep them. They can be implemented in the same lint pass, though.

[fmease]

So I gonna to add a diagnostic item on each public module exported by rustc_type_ir.

This won't be sufficient because the crate root of rustc_type_ir not only contains modules but also a myriad of non-module items (which come from re-exports).

If #![cfg_attr(feature = "nightly", rustc_diagnostic_item = "type_ir")] in the crate root / root module of crate rustc_type_ir truly doesn't work, I would recommend patching the rustc_diagnostic_item logic in compiler/rustc_passes/src/diagnostic_items.rs. It currently goes through all the hir_crate_items() and off the top of my head I don't remember if it includes the LOCAL_CRATE.

[rperier]

So I gonna to add a diagnostic item on each public module exported by rustc_type_ir.

This won't be sufficient because the crate root of rustc_type_ir not only contains modules but also a myriad of non-module items (which come from re-exports).

Indeed, good point. The change itself is not too complicated, that's just I am discovering all in internal compiler types and architecture in the same time :D (but it's fun !)
Thank you both for your feedback and your responsiveness.

[rperier]

Sorry, bad manipulation

[rperier]

You were right, it seems that `compiler/rustc_passes/src/diagnostic_items.rs' must be adapted to include the crate owner_id. I am still running non-regressions testing, it works now :) (otherwise the lint is not emitted at all)

[rperier]

@rustbot ready

[bors]

☔ The latest upstream changes (presumably #137944) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

@bors r+ rollup

[bors]

📌 Commit a1a3bef has been approved by compiler-errors

It is now in the queue for this repository.