Internal lint: Ban pub re-exports in compiler/

[jyn514]

Proposal

This is an MCP for rust-lang/rust#65233 (Internal lint: Ban pub re-exports)

Why make this change?

• re-exports obscure which crate an item is defined in
• re-exports add non-canonical paths: should I import rustc_hir::def_id::LOCAL_CRATE or rustc_span::def_id::LOCAL_CRATE?
• re-exports can add unnecessary dependencies to the crate graph, slowing down compile times (due to lack of parallelism) and making refactors more difficult

What is the long-term goal?

The long-term goal is to split up rustc_middle as per rust-lang/rust#65031. I'm thinking of doing that by moving out rustc_middle::ty to rustc_ty, but I'm not set on that; accepting this MCP should not count as accepting the rustc_middle change.

Why not make this change?

• Churn
• You now have to care where items are defined when you didn't before.

Proposed approach

• Deny public re-exports by default.
• Allow public re-exports in the following crates/modules:
  • rustc_data_structures (as per [WIP] Internal lint: warn on public cross-crate re-exports rust#77479 (comment))
  • librustc_mir::interpret (as per Internal lint: Ban pub re-exports rust#65233 (comment))
  • Other crates can be allowed as decided by the compiler team. However, to the extent possible, I would prefer to not allow this in most crates at time of implementation, so that there's a clear distinction between 'crates intentionally not following the lint' and 'crates which have not yet been transitioned to using the lint' (by simply not having any crates in the second category).

There is a half-finished implementation of this in rust-lang/rust#77479.

Mentors or Reviewers

I am not sure who should mentor. Perhaps @lcnr is interested?

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 merge on either the MCP or the PR.
• 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.

[rustbot]

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.

[lcnr]

Can mentor/review, but not a member of t-compiler, so I don't think I can second this.

[lcnr]

compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.

didn't realize contributors can also second 😅

@rustbot second

[petrochenkov]

Looks like this is currently in FCP to accept, but one PR applying a subset of this proposal was recently closed - rust-lang/rust#77494.
So it seems like this suggestion should rather be done on case by case basis, than as a general policy.

[jyn514]

Sounds good to me.