Skip to content

Make the documentation about #![allow(unused)] more visible #65464

@ChrisJefferson

Description

@ChrisJefferson

I like to build functions as a series of parts, for example I might write the following skeleton, then plan to fill in the loop

fn sorter(x: Vec<Vec<isize>>, modifier: bool) -> Vec<isize> {
    let mut out = vec![];
    for i in x {
   
    }
    out
}

If I run a cargo check on this, just to check for typos, I get:

warning: unused variable: `i`
  --> src/playgame.rs:35:9
   |
35 |     for i in x {}
   |         ^ help: consider prefixing with an underscore: `_i`
   |
   = note: `#[warn(unused_variables)]` on by default

warning: unused variable: `modifier`
  --> src/playgame.rs:33:31
   |
33 | fn sorter(x: Vec<Vec<isize>>, modifier: bool) -> Vec<isize> {
   |                               ^^^^^^^^ help: consider prefixing with an underscore: `_modifier`

warning: variable does not need to be mutable
  --> src/playgame.rs:34:9
   |
34 |     let mut out = vec![];
   |         ----^^^
   |         |
   |         help: remove this `mut`
   |
   = note: `#[warn(unused_mut)]` on by default

warning: function is never used: `sorter`
  --> src/playgame.rs:33:1
   |
33 | fn sorter(x: Vec<Vec<isize>>, modifier: bool) -> Vec<isize> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

I feel it should be possible to encapsulate a set of warnings which represent "unused/dead", and have a way of disabling them while developing. I realise this could be abused by some people, but I find it hard to spot the important issues between these unused/dead issues while developing.

Metadata

Metadata

Assignees

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.C-enhancementCategory: An issue proposing an enhancement or a PR with one.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions