WIP: Lint unused features #152164

mu001999 · 2026-02-05T11:39:56Z

jyn514

this is neat! in the future, it would be easier to review if you split the rename into a separate commit from the change in behavior.

could you add some tests for this please?

View changes since this review

compiler/rustc_interface/src/passes.rs

mu001999 · 2026-02-05T15:33:26Z

Initial implementation completed. I plan to add more tests and check whether features in rustc are reported as unused correctly or not.

compiler/rustc_feature/src/unstable.rs

jyn514 · 2026-02-10T11:17:54Z

compiler/rustc_feature/src/unstable.rs

+                // `restricted_std` is declared to mark std as unstable for certain targets,
+                // but it has no direct call sites to record usage, so it should never lint.
+                && f.as_str() != "restricted_std"


this is confusing to me — do you mean it's only checked downstream by a later invocation of the compiler? like, when std is no longer the local crate?

This library feature is declared in

rust/library/std/src/lib.rs

Lines 750 to 754 in f21b4c0

// This is required to avoid an unstable error when `restricted-std` is not

// enabled. The use of #![feature(restricted_std)] in rustc-std-workspace-std

// is unconditional, so the unstable feature needs to be defined somewhere.

#[unstable(feature = "restricted_std", issue = "none")]

mod __restricted_std_workaround {}

It is only on the private mod, so that it cannot be recorded as used in downstream crates, and will always be an unused feature.

But I'm not sure it's the best way to solve this. Because we can define such features arbitrarily. And as we know they will be always unused, maybe users who use such features should allow unused_features manually or export a pub thing like pub mod workaround {} to make them used? 🤔

mu001999 · 2026-02-11T02:34:30Z

Nice, CI has passes (finally :)), although I allowed unused_features somewhere (I try to only allow when there are complex platform-specific features enabled). But I think the next could be to merge the removal of unused features separately.

bjorn3 · 2026-02-12T13:45:53Z

compiler/rustc_feature/src/unstable.rs

 }

+static USED_FEATURES: LazyLock<Mutex<FxHashSet<Symbol>>> =
+    LazyLock::new(|| Mutex::new(FxHashSet::default()));


Can you put this in the Session instead to correctly handle multiple compiler sessions in the same process?

Also how are you ensuring that it works correctly with incr comp? Something needs to either record the side effects of marking a feature as used or force the query that marks a feature as used to be rerun.

Can you put this in the Session instead to correctly handle multiple compiler sessions in the same process?

Done. Thanks for the advice!

Also how are you ensuring that it works correctly with incr comp?

The query tracked_features_query is marked as eval_always and no_hash (as you suggested in the deleted comment, I thought wrongly that just the eval_always could make the node always red), so that any other queries depend on it (tcx.features() in fact) will re-compute. And then, checking the features is enabled or not will mark it as used in this table.

And TrackedFeatures does not implement HashStable, queries that depend on it can only check the feature internally but cannot pass or return TrackedFeatures to cause a unexpected usage outside query system. Therefore, as long as no other parts of the code directly use TrackedFeatures, it should work correctly with incremental compilation.

bjorn3 · 2026-02-12T15:00:33Z

compiler/rustc_query_system/src/ich/impls_syntax.rs

+        self.enabled_lang_features().hash_stable(hcx, hasher);
+        self.enabled_lib_features().hash_stable(hcx, hasher);
+    }
+}


Is this still necessary with the no_hash?

This has been removed in the third commit. Let me squash these two commits.

Put USED_FEATURES in the Session and mark tracked_features_query no_hash