484
struct SemanticDirection;

fn main() {}
warning: struct is never used: `SemanticDirection`
 --> src/main.rs:1:1
  |
1 | struct SemanticDirection;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(dead_code)] on by default

I will turn these warnings back on for anything serious, but I am just tinkering with the language and this is driving me bats.

I tried adding #[allow(dead_code)] to my code, but that did not work.

Ryan M
  • 18,333
  • 31
  • 67
  • 74
Andrew Wagner
  • 22,677
  • 21
  • 86
  • 100

12 Answers12

763

You can either:

  • Add an allow attribute on a struct, module, function, etc.:

    #[allow(dead_code)]
    struct SemanticDirection;
    
  • Add a crate-level allow attribute; notice the !:

    #![allow(dead_code)]
    
  • Pass it to rustc:

    rustc -A dead_code main.rs
    
  • Pass it using cargo via the RUSTFLAGS environment variable:

    RUSTFLAGS="$RUSTFLAGS -A dead_code" cargo build
    
Serid
  • 354
  • 6
  • 13
Arjan
  • 19,957
  • 2
  • 55
  • 48
105

Another way to disable this warning is to prefix the identifier by _:

struct _UnusedStruct {
    _unused_field: i32,
}

fn main() {
    let _unused_variable = 10;
}

This can be useful, for instance, with an SDL window:

let _window = video_subsystem.window("Rust SDL2 demo", 800, 600);

Prefixing with an underscore is different from using a lone underscore as the name. Doing the following will immediately destroy the window, which is unlikely to be the intended behavior.

let _ = video_subsystem.window("Rust SDL2 demo", 800, 600);
Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
antoyo
  • 11,097
  • 7
  • 51
  • 82
  • 4
    That "assigning to underscore will destroy it" behavior seems odd (though I don't doubt you're correct). Do you have a reference for it? – Michael Anderson Jul 06 '18 at 05:29
  • 11
    @MichaelAnderson See "RAII. You might want to have a variable exist for its destructor side effect, but not use it otherwise. It is not possible to use simply _ for this use-case, as _ is not a variable binding and the value would be dropped at the end of the statement." from https://stackoverflow.com/a/48361729/109618 – David J. Jul 07 '18 at 21:26
  • 3
    using `let _ =` the value would be dropped at the end of the statement, not the end of the block – nicolas Sep 26 '20 at 08:04
  • If you want to read more about why, the reason is that the `X` in `let X = Y` is an irrefutable pattern (i.e. it's like a `match` arm that can be proved to never be wrong at compile time) and, like with refutable patterns, `_` is a wildcard that doesn't bind anything to a variable. That's why and how you can do `let (x, y) = foo();` and other sorts of unpacking like that. It's just another kind of irrefutable pattern. – ssokolow Dec 21 '20 at 21:16
59

Put these two lines on the top of the file.

#![allow(dead_code)]
#![allow(unused_variables)]
M. Hamza Rajput
  • 7,810
  • 2
  • 41
  • 36
  • what's the difference those two? #[allow(dead_code)] not works but #![allow(dead_code)] works. – jwkoo Dec 04 '21 at 09:52
  • 4
    @jwkoo the ! makes it apply to the entire crate – Connor Dec 23 '21 at 00:41
  • 17
    Replace with `#![allow(dead_code, unused)]` ;-) – jaques-sam May 06 '22 at 15:28
  • 2
    @jaques-sam `dead_code` and `unused_variables` are subsets of `unused` (with many more lints) which likely is too board to silence the linter for something specific. The different between the lints is detailed in this answer: https://stackoverflow.com/a/64556868/175584 – Cas Feb 22 '23 at 17:49
  • would allow bloat of the final binary size? or would that not happen? – user1709076 May 10 '23 at 15:06
  • @user1709076 `allow` annotations only influence the compiler diagnostics (warnings/errors). They don't change anything for the final binary and usually the compiler is smart enough to remove unused code/variables. Unused code of course still impacts compile time and *might* increase binary size, regardless of the use of `allow`. – cg909 Jun 12 '23 at 14:28
35

Making the code public also stops the warnings; you'll need to make the enclosing mod's public too.

This makes sense when you're writing a library: your code is "unused" internally because it's intended to be used by client code.

Victor Basso
  • 5,556
  • 5
  • 42
  • 60
  • 1
    I think this does not work if the crate contains both a main.rs and a lib.rs, and the main.rs does not use the function under question. – hoijui Sep 12 '21 at 09:37
8

also as an addition: rust provides four levels of lints (allow, warn, deny, forbid).

https://doc.rust-lang.org/rustc/lints/levels.html#lint-levels

Muhammed Moussa
  • 4,589
  • 33
  • 27
6
  • Directly way to just put the following in the head of the file

    #![allow(dead_code, unused_variables)]

    • The dead_code lint detects unused, unexported items.
    • The unused_variables lint detects variables which are not used in any way.
  • More simple way is to put the following in the head of the file

    #![allow(unused)]

Ref: rust lint list

zangw
  • 43,869
  • 19
  • 177
  • 214
5

You can add the #[allow(dead_code)] attribute to the struct definition like so:

#[allow(dead_code)]
struct SemanticDirection;

Or you can disable the warning for the entire file by adding the attribute at the top of the file, like so:

#![allow(dead_code)]

struct SemanticDirection;

But these attributes only work if you have the dead_code lint enabled. By default, the dead_code lint is enabled in Rust, but you can disable it by adding the following to the top of your code:

#![deny(dead_code)]

This will disable the dead_code lint for the entire file.

It's generally a good idea to keep the dead_code lint enabled, as it can help you catch mistakes in your code and ensure that you are not introducing unnecessary code into your project. However, it can be annoying when you are just experimenting and trying out different things, so it's understandable if you want to disable it in those cases.

AlexaP
  • 179
  • 2
  • 1
4

For unused functions, you should make the function public, but watch out. If the struct isn't public, then you'll still get the error as in here:

//this should be public also
struct A{
   A{}
}

impl A {
    pub fn new() -> A {

    }
}

Or if you don't want it to be public, you should put #[allow(unused)]

PPP
  • 1,279
  • 1
  • 28
  • 71
3

You can always disable unused variables/functions by adding an (_) to the variable name, like so:

let _variable = vec![0; 10];
3

At the top of *.rs file:

#![allow(unused)]  // FIXME
Evgene
  • 446
  • 4
  • 8
1

add this in 1st line of code

#![allow(unused_variables)]

all warnings solutions:

https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html

aakash4dev
  • 774
  • 4
  • 13
  • It seems this helps only for this specific warning (unused variables). Using `#![allow(unused)]` seems tot fix all unused warnings (e.g. unused macros, imports, dead code, etc.). – Matthijs Kooijman Apr 13 '23 at 06:11
-8

using features

#[cfg(feature = "dead_code")]

note: "dead_code" can be replaced by any word.

davidsbro
  • 2,761
  • 4
  • 23
  • 33
jmzhou
  • 1
  • 2
    I have never seen cfg/feature used like this. Can you explain how this works, or is it documented somewhere? – MB-F Jan 14 '22 at 22:11