New lints: `#[must_use]` removed

[obi1kenobi]

I also think I am inadvertently suggesting another lint: If a maintainer removes a must_use, in version 1.2.3 and someone writes code without removing it, that person cannot downgrade to 1.2.2 without clippy breaking. Therefore, removing a must_use would also be a minor bump.

Originally posted by @schneems in #1278

This would be in the same category as non-breaking API additions: it should be allow-by-default and opt-in.

We'll need variants of the lint for all places where #[must_use] may appear. Use the existing "#[must_use] removed" lints to guide where a corresponding removal lint should exist.

• struct_must_use_removed: Add struct_must_use_removed #1392
• inherent_method_must_use_removed: Inherent method must_use removed #1516
• function_must_use_removed: Add function_must_use_removed #1400
• trait_must_use_removed: Add lint trait_must_use_removed #1515
• union_must_use_removed: Add union_must_use_removed #1399

Rust 1.89 has a bug around #[must_use] that makes the attribute not appear as expected in rustdoc JSON. You'll likely need to add each new lint here to the list of exemptions for Rust 1.89 tests here Our minimum supported Rust version is 1.90+ so the 1.89 bug is no longer a concern.

[nk9]

Given that the code for this lint has been merged, can this issue be closed?

[obi1kenobi]

No — there are many more lints to write here. Updated the top post with a list.

[nk9]

I'd like to give this a try, but I'm new to trustfall. I was thinking of tackling struct_must_use_removed and modeling it on the just-completed enum_must_use_removed. Does that seem like a good starting point?

[obi1kenobi]

Yeah! Between struct_must_use_added and enum_must_use_removed you should have everything you need in the query. Also make sure to check out the contributing guide for writing new lints, there are some useful scripts you should make use of.

[nk9]

I've implemtented the lint, and created the old and new test crates. I ran cargo test and saw my test failing as expected, along with a couple of other related tests (equivalent to the ones which also changed in the enum_must_use_removed lint). I included those added lines in my commit. However, there are a bunch of other failing tests which I don't understand. For example:

Snapshot failure excerpt inside

━━━━━━━━━━━━━━━━━━━━━━━━━━ Snapshot Summary ━━━━━━━━━━━━━━━━━━━━━━━━━━
Snapshot file: src/../test_outputs/query_execution/unsafe_trait_method_requires_more_target_features.snap
Snapshot: unsafe_trait_method_requires_more_target_features
Source: src/query.rs:875
──────────────────────────────────────────────────────────────────────
Expression: &query_execution_results
──────────────────────────────────────────────────────────────────────
-old snapshot
+new results
────────────┬─────────────────────────────────────────────────────────
    0       │-{
    1       │-  "./test_crates/unsafe_trait_method_requires_more_target_features/": [
    2       │-    {
    3       │-      "currently_unsafe": Boolean(true),
    4       │-      "method_name": String("unsafe_method"),
    5       │-      "name": String("TraitA"),
    6       │-      "new_feature": String("avx2"),
    7       │-      "path": List([
    8       │-        String("unsafe_trait_method_requires_more_target_features"),
    9       │-        String("TraitA"),
   10       │-      ]),
   11       │-      "span_begin_line": Uint64(10),
   12       │-      "span_end_line": Uint64(10),
   13       │-      "span_filename": String("src/lib.rs"),
   14       │-    },
   15       │-    {
   16       │-      "currently_unsafe": Boolean(true),
   17       │-      "method_name": String("sealed_trait_method"),
   18       │-      "name": String("TraitSealed"),
   19       │-      "new_feature": String("avx2"),
   20       │-      "path": List([
   21       │-        String("unsafe_trait_method_requires_more_target_features"),
   22       │-        String("TraitSealed"),
   23       │-      ]),
   24       │-      "span_begin_line": Uint64(16),
   25       │-      "span_end_line": Uint64(16),
   26       │-      "span_filename": String("src/lib.rs"),
   27       │-    },
   28       │-  ],
   29       │-}
          0 │+{}
────────────┴─────────────────────────────────────────────────────────

There are 11 tests which are failing which I don't understand:

    query::tests_lints::safe_function_requires_more_target_features
    query::tests_lints::safe_function_target_feature_added
    query::tests_lints::safe_inherent_method_requires_more_target_features
    query::tests_lints::safe_inherent_method_target_feature_added
    query::tests_lints::trait_method_target_feature_removed
    query::tests_lints::unsafe_function_requires_more_target_features
    query::tests_lints::unsafe_function_target_feature_added
    query::tests_lints::unsafe_inherent_method_requires_more_target_features
    query::tests_lints::unsafe_inherent_method_target_feature_added
    query::tests_lints::unsafe_trait_method_requires_more_target_features
    query::tests_lints::unsafe_trait_method_target_feature_added

Shall I commit what I have so you can repro yourself? Or do you already have some idea of what I'm missing?

[nk9]

Aah, I removed my changes and ran cargo test again and: the same 11 tests fail. So I think this isn't my fault. 😄

[obi1kenobi]

Try updating your local Rust version to use latest nightly, then regenerating the rustdoc JSON data. I think there's a bugfix in beta and nightly that isn't on stable yet, and is causing false negatives and false positives on a few lints.

…

On Thu, Aug 21, 2025, 6:29 PM Nick Kocharhook ***@***.***> wrote: *nk9* left a comment (obi1kenobi/cargo-semver-checks#1279) <#1279 (comment)> Aah, I removed my changes and ran cargo test again and: the same 11 tests fail. So I think this isn't my fault. 😄 — Reply to this email directly, view it on GitHub <#1279 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR5MSXPAWO4O4XCXARNUED3OZB3JAVCNFSM6AAAAAB6WVLEF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMJSGI2TMOJSGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>