Skip to content

suggest adding #[test] on otherwise-dead code that looks like a test? #33166

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sourcefrog opened this issue Apr 23, 2016 · 4 comments
Closed
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-feature-request Category: A feature request, i.e: not implemented / a PR.

Comments

@sourcefrog
Copy link
Contributor

On this code:

#[cfg(test)]
mod tests {

    pub fn test_addition() {
        assert_eq!(2+2, 4);
    }
}

I currently get

function is never used: `test_addition`, #[warn(dead_code)] on by default

What I need here is a #[test] before the function of course. Perhaps rustc could suggest this if some of the following hints are seen

  • it's in #[cfg(test)]
  • it's in a submodule tests
  • the function's called test_*

I don't know if making suggestions based on names is considered unhygienic, but this would remove a small speed bump for new users.

@sourcefrog sourcefrog changed the title suggest adding #[test]? suggest adding #[test] on otherwise-dead code? Apr 23, 2016
@sourcefrog sourcefrog changed the title suggest adding #[test] on otherwise-dead code? suggest adding #[test] on otherwise-dead code that looks like a test? Apr 23, 2016
@GuillaumeGomez
Copy link
Member

That's maybe a bit too much? The idea is good but I'm afraid it might overload the output. Let's see what others think about it.

@steveklabnik steveklabnik added the A-diagnostics Area: Messages for errors, warnings, and lints label Jun 6, 2016
@steveklabnik
Copy link
Member

the function's called test_*

In general, naming your function with test doesn't seem idiomatic to me; it leads to duplicated output with the test runner.

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 25, 2017
@Mark-Simulacrum
Copy link
Member

I personally think this is better suited as e.g. a clippy lint and doesn't really make sense for a compiler lint as there'd be too many false positives. It's also true that having helper functions inside cfg(test) is pretty common (at least in my experience), so that's another source of false positives. I'm going to go ahead and close this in favor of adding this to clippy and then if there's wide usage it can eventually be migrated into rustc through the RFC process.

@sourcefrog
Copy link
Contributor Author

sourcefrog commented Sep 1, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-feature-request Category: A feature request, i.e: not implemented / a PR.
Projects
None yet
Development

No branches or pull requests

4 participants