Lint unused pub items in binary crates

[mu001999]

View all comments

This PR adds a new unstable flag -Ztreat-pub-as-pub-crate as @Kobzol suggested.
When compiling binary crates with this flag, the seed worklist will only contain the entry fn and won't contain other reachable items. Then we can do the dead code analysis for pub items just like they are pub(crate).

Related zulip thread #general > pub/pub(crate) within a binary is a footgun.

---

Updated:

Adds a new lint unused_pub_items_in_binary (crate-level, default allow for now) instead of the previous unstable flag to lint unused pub items for binary crates.

See more details of implementation in #149509 (comment).

This lint is allowed by default, but I believe this has been better than the unstable flag. Making it warn-by-default will lead to a lot of noise for this PR (like bless many tests). So I'd like to make it warn-by-default in a separate PR in the future.

[rustbot]

r? @jdonszelmann

rustbot has assigned @jdonszelmann.
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

[Noratrieb]

What are the plans for this flag? Being made the default? As just a flag, it's essentially useless, because no one will know about it. So I'd be opposed to just adding it without any plan for making it useful for everyone.

[mu001999]

Maybe this could be a separate lint, I haven't thought too clearly yet

[jdonszelmann]

Yea I do agree with nora here, maybe open a (specific) zulip thread to make a proper plan for this?

[jdonszelmann]

I guess I'd prefer this as a lint (attribute at the crate root) myself

[jdonszelmann]

@rustbot author

[rustbot]

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

[Kobzol]

I guess that the use-case that I'm envisioning is to have an opt-in way to treat pub stuff as pub(crate) in binary crates. If it was an allow-by-default lint, which could be manually denied, that would serve that use-case, I think.

[GrantGryczan]

Why would the end goal be for this to be opt-in? I and others want to see #74970 become a default. I wouldn't opt into this, because that would make my codebase less idiomatic, diverging from how everyone else who hasn't opted in uses pub.

The reason this is useful as a default is because it doesn't semantically make sense to distinguish between pub and pub(crate) in binary crates. This creates a footgun because, for example, pub items can't receive dead_code warnings. If it's just opt-in, then that doesn't remove the footgun for anyone who hasn't opted in, and I don't see a benefit to pub and pub(crate) being distinct in binary crates.

The only reason I can see that someone might not want to opt into this is that one might use pub to prevent dead_code warnings as opposed to pub(crate). But I think this intent might be better communicated using #[expect(dead_code)] rather than the implicit behavior of pub. Dead code detection is useful as a default. (The only downside to that is that you then have to remove the #[expect(dead_code)] if you later use it, but I'll leave it to others to decide if that coupling is an important consideration.)

[traviscross]

We talked about this at the tail end of the lang call today. The three of us present were OK with the new name dead_code_pub_in_binary. This is good to go as far as lang is concerned.

Name changed.

[jdonszelmann]

Already said I was okay with the implementation, don't think anything changed since. @bors r+

[rust-bors]

📌 Commit 93abcca has been approved by jdonszelmann

It is now in the queue for this repository.

[JonathanBrouwer]

@bors r-
https://github.com/rust-lang/rust/actions/runs/25429503795/job/74591817259#step:28:1

[rust-bors]

This pull request was unapproved.

This PR was contained in a rollup (#156232), which was unapproved.

View changes since this unapproval

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mu001999]

@bors r=jdonszelmann

[rust-bors]

📌 Commit 26bfcf3 has been approved by jdonszelmann

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: jdonszelmann
Duration: 3h 9m 40s
Pushing 0e5924a to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 4ddd453 (parent) -> 0e5924a (this PR)

Test differences

Show 814 test diffs

Stage 1

• [ui] tests/ui/lint/dead-code-pub-in-binary/allow-dead-code-transitive.rs: [missing] -> pass (J1)
• [ui] tests/ui/lint/dead-code-pub-in-binary/allow-lint.rs: [missing] -> pass (J1)
• [ui] tests/ui/lint/dead-code-pub-in-binary/basic.rs: [missing] -> pass (J1)
• [ui] tests/ui/lint/dead-code-pub-in-binary/deny-lint.rs: [missing] -> pass (J1)
• [ui] tests/ui/lint/dead-code-pub-in-binary/interaction-allow-dead-code.rs: [missing] -> pass (J1)
• [ui] tests/ui/lint/dead-code-pub-in-binary/interaction-allow-unused-pub.rs: [missing] -> pass (J1)
• [ui] tests/ui/lint/dead-code-pub-in-binary/interaction-deny-dead-code-only.rs: [missing] -> pass (J1)
• [ui] tests/ui/lint/dead-code-pub-in-binary/library.rs: [missing] -> pass (J1)
• [ui] tests/ui/lint/dead-code-pub-in-binary/no-mangle-items.rs: [missing] -> pass (J1)

Stage 2

• [ui] tests/ui/lint/dead-code-pub-in-binary/allow-dead-code-transitive.rs: [missing] -> pass (J0)
• [ui] tests/ui/lint/dead-code-pub-in-binary/allow-lint.rs: [missing] -> pass (J0)
• [ui] tests/ui/lint/dead-code-pub-in-binary/basic.rs: [missing] -> pass (J0)
• [ui] tests/ui/lint/dead-code-pub-in-binary/deny-lint.rs: [missing] -> pass (J0)
• [ui] tests/ui/lint/dead-code-pub-in-binary/interaction-allow-dead-code.rs: [missing] -> pass (J0)
• [ui] tests/ui/lint/dead-code-pub-in-binary/interaction-allow-unused-pub.rs: [missing] -> pass (J0)
• [ui] tests/ui/lint/dead-code-pub-in-binary/interaction-deny-dead-code-only.rs: [missing] -> pass (J0)
• [ui] tests/ui/lint/dead-code-pub-in-binary/library.rs: [missing] -> pass (J0)
• [ui] tests/ui/lint/dead-code-pub-in-binary/no-mangle-items.rs: [missing] -> pass (J0)

Additionally, 796 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-21-1, aarch64-msvc-1, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, optional-x86_64-gnu-parallel-frontend, test-various, x86_64-gnu, x86_64-gnu-debug, x86_64-gnu-gcc, x86_64-gnu-llvm-21, x86_64-gnu-llvm-21-2, x86_64-gnu-llvm-22-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
• J1: x86_64-gnu-llvm-21-3, x86_64-gnu-llvm-22-3

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 0e5924a4a0b57f2c6bc8cac93f59281e68541a91 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-gnu-llvm-21: 1h 1m -> 1h 22m (+34.1%)
2. dist-apple-various: 1h 41m -> 2h 6m (+24.1%)
3. dist-i586-gnu-i586-i686-musl: 1h 36m -> 1h 16m (-20.8%)
4. armhf-gnu: 1h 33m -> 1h 14m (-20.7%)
5. x86_64-rust-for-linux: 41m 19s -> 49m 46s (+20.5%)
6. dist-loongarch64-linux: 1h 51m -> 1h 30m (-18.5%)
7. dist-armv7-linux: 1h 30m -> 1h 14m (-18.1%)
8. dist-x86_64-apple: 1h 55m -> 2h 12m (+14.1%)
9. dist-aarch64-msvc: 1h 40m -> 1h 52m (+11.4%)
10. x86_64-gnu-llvm-22-2: 1h 39m -> 1h 27m (-11.3%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (0e5924a): comparison URL.

Overall result: ❌ regressions - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 0.4%]	4
Regressions ❌ (secondary)	0.1%	[0.1%, 0.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.1%, 0.4%]	4

Max RSS (memory usage)

Results (primary 0.1%, secondary -0.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.9%	[1.9%, 1.9%]	1
Regressions ❌ (secondary)	2.4%	[2.3%, 2.5%]	2
Improvements ✅ (primary)	-1.7%	[-1.7%, -1.7%]	1
Improvements ✅ (secondary)	-2.7%	[-6.2%, -0.4%]	3
All ❌✅ (primary)	0.1%	[-1.7%, 1.9%]	2

Cycles

Results (primary -5.5%, secondary 0.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.8%	[0.7%, 3.9%]	3
Improvements ✅ (primary)	-5.5%	[-8.4%, -2.6%]	2
Improvements ✅ (secondary)	-0.6%	[-0.9%, -0.4%]	3
All ❌✅ (primary)	-5.5%	[-8.4%, -2.6%]	2

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 499.861s -> 498.18s (-0.34%)
Artifact size: 394.98 MiB -> 394.99 MiB (0.00%)