Giter Club home page Giter Club logo

rust-clippy-autopilot's Introduction

Clippy

Clippy Test License: MIT OR Apache-2.0

A collection of lints to catch common mistakes and improve your Rust code.

There are over 600 lints included in this crate!

Lints are divided into categories, each with a default lint level. You can choose how much Clippy is supposed to annoy help you by changing the lint level by category.

Category Description Default level
clippy::all all lints that are on by default (correctness, suspicious, style, complexity, perf) warn/deny
clippy::correctness code that is outright wrong or useless deny
clippy::suspicious code that is most likely wrong or useless warn
clippy::style code that should be written in a more idiomatic way warn
clippy::complexity code that does something simple but in a complex way warn
clippy::perf code that can be written to run faster warn
clippy::pedantic lints which are rather strict or have occasional false positives allow
clippy::restriction lints which prevent the use of language and library features1 allow
clippy::nursery new lints that are still under development allow
clippy::cargo lints for the cargo manifest allow

More to come, please file an issue if you have ideas!

The restriction category should, emphatically, not be enabled as a whole. The contained lints may lint against perfectly reasonable code, may not have an alternative suggestion, and may contradict any other lints (including other categories). Lints should be considered on a case-by-case basis before enabling.


Table of contents:

Usage

Below are instructions on how to use Clippy as a cargo subcommand, in projects that do not use cargo, or in Travis CI.

As a cargo subcommand (cargo clippy)

One way to use Clippy is by installing Clippy through rustup as a cargo subcommand.

Step 1: Install Rustup

You can install Rustup on supported platforms. This will help us install Clippy and its dependencies.

If you already have Rustup installed, update to ensure you have the latest Rustup and compiler:

rustup update

Step 2: Install Clippy

Once you have rustup and the latest stable release (at least Rust 1.29) installed, run the following command:

rustup component add clippy

If it says that it can't find the clippy component, please run rustup self update.

Step 3: Run Clippy

Now you can run Clippy by invoking the following command:

cargo clippy

Automatically applying Clippy suggestions

Clippy can automatically apply some lint suggestions, just like the compiler. Note that --fix implies --all-targets, so it can fix as much code as it can.

cargo clippy --fix

Workspaces

All the usual workspace options should work with Clippy. For example the following command will run Clippy on the example crate:

cargo clippy -p example

As with cargo check, this includes dependencies that are members of the workspace, like path dependencies. If you want to run Clippy only on the given crate, use the --no-deps option like this:

cargo clippy -p example -- --no-deps

Using clippy-driver

Clippy can also be used in projects that do not use cargo. To do so, run clippy-driver with the same arguments you use for rustc. For example:

clippy-driver --edition 2018 -Cpanic=abort foo.rs

Note that clippy-driver is designed for running Clippy only and should not be used as a general replacement for rustc. clippy-driver may produce artifacts that are not optimized as expected, for example.

Travis CI

You can add Clippy to Travis CI in the same way you use it locally:

language: rust
rust:
  - stable
  - beta
before_script:
  - rustup component add clippy
script:
  - cargo clippy
  # if you want the build job to fail when encountering warnings, use
  - cargo clippy -- -D warnings
  # in order to also check tests and non-default crate features, use
  - cargo clippy --all-targets --all-features -- -D warnings
  - cargo test
  # etc.

Note that adding -D warnings will cause your build to fail if any warnings are found in your code. That includes warnings found by rustc (e.g. dead_code, etc.). If you want to avoid this and only cause an error for Clippy warnings, use #![deny(clippy::all)] in your code or -D clippy::all on the command line. (You can swap clippy::all with the specific lint category you are targeting.)

Configuration

Allowing/denying lints

You can add options to your code to allow/warn/deny Clippy lints:

  • the whole set of Warn lints using the clippy lint group (#![deny(clippy::all)]). Note that rustc has additional lint groups.

  • all lints using both the clippy and clippy::pedantic lint groups (#![deny(clippy::all)], #![deny(clippy::pedantic)]). Note that clippy::pedantic contains some very aggressive lints prone to false positives.

  • only some lints (#![deny(clippy::single_match, clippy::box_vec)], etc.)

  • allow/warn/deny can be limited to a single function or module using #[allow(...)], etc.

Note: allow means to suppress the lint for your code. With warn the lint will only emit a warning, while with deny the lint will emit an error, when triggering for your code. An error causes clippy to exit with an error code, so is useful in scripts like CI/CD.

If you do not want to include your lint levels in your code, you can globally enable/disable lints by passing extra flags to Clippy during the run:

To allow lint_name, run

cargo clippy -- -A clippy::lint_name

And to warn on lint_name, run

cargo clippy -- -W clippy::lint_name

This also works with lint groups. For example, you can run Clippy with warnings for all lints enabled:

cargo clippy -- -W clippy::pedantic

If you care only about a single lint, you can allow all others and then explicitly warn on the lint(s) you are interested in:

cargo clippy -- -A clippy::all -W clippy::useless_format -W clippy::...

Configure the behavior of some lints

Some lints can be configured in a TOML file named clippy.toml or .clippy.toml. It contains a basic variable = value mapping e.g.

avoid-breaking-exported-api = false
disallowed-names = ["toto", "tata", "titi"]

The table of configurations contains all config values, their default, and a list of lints they affect. Each configurable lint , also contains information about these values.

For configurations that are a list type with default values such as disallowed-names, you can use the unique value ".." to extend the default values instead of replacing them.

# default of disallowed-names is ["foo", "baz", "quux"]
disallowed-names = ["bar", ".."] # -> ["bar", "foo", "baz", "quux"]

Note

clippy.toml or .clippy.toml cannot be used to allow/deny lints.

To deactivate the “for further information visit lint-link” message you can define the CLIPPY_DISABLE_DOCS_LINKS environment variable.

Specifying the minimum supported Rust version

Projects that intend to support old versions of Rust can disable lints pertaining to newer features by specifying the minimum supported Rust version (MSRV) in the clippy configuration file.

msrv = "1.30.0"

Alternatively, the rust-version field in the Cargo.toml can be used.

# Cargo.toml
rust-version = "1.30"

The MSRV can also be specified as an attribute, like below.

#![feature(custom_inner_attributes)]
#![clippy::msrv = "1.30.0"]

fn main() {
  ...
}

You can also omit the patch version when specifying the MSRV, so msrv = 1.30 is equivalent to msrv = 1.30.0.

Note: custom_inner_attributes is an unstable feature, so it has to be enabled explicitly.

Lints that recognize this configuration option can be found here

Contributing

If you want to contribute to Clippy, you can find more information in CONTRIBUTING.md.

License

Copyright 2014-2023 The Rust Project Developers

Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or https://opensource.org/licenses/MIT>, at your option. Files in the project may not be copied, modified, or distributed except according to those terms.

Footnotes

  1. Some use cases for restriction lints include:

rust-clippy-autopilot's People

Contributors

bors avatar oli-obk avatar flip1995 avatar manishearth avatar mcarton avatar phansch avatar llogiq avatar matthiaskrgr avatar jarcho avatar camsteffen avatar xfrednet avatar johntitor avatar tesuji avatar ebroto avatar alexendoo avatar thibsg avatar birkenfeld avatar smoelius avatar giraffate avatar centri3 avatar sinkuu avatar tako8ki avatar y-nak avatar rail-rain avatar cjgillot avatar dswij avatar devonhollowood avatar y21 avatar serial-ata avatar blyxyas avatar

rust-clippy-autopilot's Issues

Build extra code for this repository to be convenient with the description

Description

Please read the following text, understand it and convert the current repository to have what it asks the text:

`What is a Codacy tool
A Codacy Tool is a Docker-based container that wraps linters or tools, ingesting their result and outputting a standardised json document that can be ingested by Codacy. The accepted output format can be found at Output format section.

As input the tool accepts a configuration file, .codacyrc.

How to integrate an external analysis tool on Codacy
By creating a docker and writing code to handle the tool invocation and output, you can integrate the tool of your choice on Codacy!

To know more about dockers, and how to write a docker file please refer to https://docs.docker.com/reference/builder/

You can check the code of an already implemented tool and, if you wish, fork it to start your own. You are free to modify and use it for your own tools.

Structure
In order to run the tool, it's necessary to include a configuration file /.codacyrc, containing information about the language and potential additional parameters.
The source code to be analysed will be located in /src, meaning that when provided in the configuration, the file paths are relative to /src.
Structure of the .codacyrc file
This file has:

files: Files to be analysed (their path is relative to /src)
tools: Array of tools
name: Unique identifier of the tool. This will be provided by the tool in patterns.json file.
patterns: Array of patterns that must be checked
patternId: Unique identifier of the pattern
parameters: Parameters of the pattern
name: Unique identifier of the parameter
value: Value to be used as parameter value
{
"files" : ["foo/bar/baz.js", "foo2/bar/baz.php"],
"tools":[
{
"name":"jshint",
"patterns":[
{
"patternId":"latedef",
"parameters":[
{
"name":"latedef",
"value":"vars"
}
]
}
]
}
]
}
Behavior of the configuration file
The tool parses the configuration file provided and uses it to define its own behaviour. This configuration file is the way to specify which source files to analyse and which patterns to include in that analysis.

Depending on the configuration, the tool should have different behaviours for the following situations:

If /.codacyrc exists:

Patterns defined and no files -> use the patterns to invoke the tool for all source files inside /src

Files defined and no patterns -> run tool's default configuration file on the source files specified

Patterns and files defined -> run tool using patterns specified on the source files passed

Patterns and files not specified -> run the tool for all source files on /src using the tool's native configuration or with the default patterns (if native configuration does not exist)

If /.codacyrc does not exist, run the tool for all source files on /src using the tool's native configuration or with the default patterns (if native configuration does not exist).

If /.codacyrc fails to be parsed, throw an error.

General tool behavior
Exit codes:

The exit codes are different, depending on the tool invocation is successful or not:
0: The tool executed successfully 🎉
1: An unknown error occurred while running the tool 😰
2: Execution timeout ⏰
Environment variables:

To run the tool in debug mode, so you can have more detailed logs, you need to set the environment variable DEBUG to true when invoking the docker.
To configure a different timeout for the tool, you have to set the environment variable TIMEOUT_SECONDS when you run the docker image, setting it with values like 10 or 1800 (30 minutes).
Output format
After you have your results from the tool, you should print them to the standard output, one per line:

filename: file where the issue was found
message: issue message returned by the linter
patternId: pattern the issue corresponds to
line: line where the issue was found
{
"filename":"codacy/core/test.js",
"message":"found this in your code",
"patternId":"latedef",
"line":2
}
The filename should not be the absolute path (not include the /src/) /src/codacy/core/test.js should be returned as codacy/core/test.js

Setup
Requirements
Docker
Write the docker file that will run the tool.

It must have a binary entry point without any parameters.
Write a patterns.json (schema) with the configuration of your tool.

This file must be located on /docs/patterns.json.
name: Unique identifier of the tool (lower-case letters without spaces)
version: Tool version to display in the Codacy UI
patterns: The patterns that the tool provides
patternId: Unique identifier of the pattern (lower-case letters without spaces)
level: Severity level of the issue
category: Category of the issue
parameters: Parameters received by the pattern
name: Unique identifier of the parameter (lower-case letters without spaces)
default: Default value of the parameter. The tool must ensure the default value is used when it is not sent on the configuration file.
{
"name":"jshint",
"version": "1.2.3",
"patterns":[
{
"patternId": "latedef",
"category": "ErrorProne",
"parameters": [
{
"name": "latedef",
"default": "nofunc"
}
],
"level": "Warning"
}
]
}
Write the code to run the tool

You can write the code in any language you want but, you have to invoke the tool according to the configuration. After you have your results from the tool, you should print them to the standard output in our Result format (schema), one result per line.

The filename should not include the prefix "/src/". Example:

absolute path: /src/folder/file.js
filename path: folder/file.js
{
"filename":"codacy/core/test.js",
"message":"found this in your code",
"patternId":"latedef",
"line":2
}
If you are not able to run the analysis for any of the files requested you should return an error for each one of them to the standard output in our Error format.

{
"filename":"codacy/core/test.js",
"message":"could not parse the file"
}
When an unknown error occurred while running the tool, it should send the error information through the standard error and exit with error code 1. See exit codes section.

Tool Documentation
At Codacy we strive to provide the best value to our users and, to accomplish that, we document our patterns so that the user can better understand the problem and fix it.

At this point, your tool has everything it needs to run, but there is one other really important thing that you should do before submitting your docker: the documentation for your tool.

Your files for this section should be placed in /docs/description/.

In order to provide more details you can create:

A single /docs/description/description.json file.
A /docs/description/.md file for each pattern.
Levels and Categories
For level types we have:

Error - High priority issues. These issues show the code that is very susceptible to problems.
Warning - You should be careful abou these issues as they are based on code standards and conventions.
Info - The least critical issue type.
For category types we have:

ErrorProne - Code that may hide bugs.
CodeStyle - Code formatting and syntax problems.
Complexity - Code that is highly complex and that should be refactored.
UnusedCode - Code that is never used
Security - Code that may have security issues
Compatibility - Compatibility problems across different versions (mainly for frontend code)
Performance - Code that has performance problems
Documentation - Methods and classes that do not have the correct comment annotations
BestPractice
Description structure
The documentation description is optional but must be added as much as possible.

In the description.json (schema) you define the title for the pattern, brief description, time to fix (in minutes), and also a description of the parameters in the following format:

[
{
"patternId": "latedef",
"title": "Enforce variable def before use",
"description": "Prohibits the use of a variable before it was defined.",
"parameters": [
{
"name": "latedef",
"description": "Declaration order verification. Check all [true] | Do not check functions [nofunc]"
}
],
"timeToFix": 10
}
]
To give a more detailed explanation about the issue, you should define the .md. Example:

Fields in interfaces are automatically public static final, and methods are
public abstract.
Classes or interfaces nested in an interface are automatically public and static
(all nested interfaces are automatically static).

For historical reasons, modifiers which are implied by the context are accepted
by the compiler, but are superfluous.

Ex:

public interface Foo {
    public abstract void bar();         // both abstract and public are ignored by the compiler
    public static final int X = 0;         // public, static, and final all ignored
    public static class Bar {}             // public, static ignored
    public static interface Baz {}         // ditto

    void foo();                            //this is correct
}

public class Bar {
    public static interface Baz {} // static ignored
}

Source
You should explain the what and why of the issue. Adding an example is always a nice way to help other people understand the problem. For a more thorough explanation you can also add a link at the end referring a more complete source.

Notes:

Documentation Generator: This documentation should also be generated automatically to avoid having to go through all of the files each time it needs to be updated.
Test
Follow the instructions at codacy-plugins-test.

Submit the docker
Running the docker:

docker run -t
--net=none
--privileged=false
--cap-drop=ALL
--user=docker
--rm=true
-v :/src:ro
:
Docker restrictions:

Docker image size should not exceed 500MB
Docker should contain a non-root user named docker with UID/GID 2004, associated with a docker group
All the source code of the docker must be public
The docker base must officially be supported on DockerHub
Your docker must be provided in a repository through a public git host (ex: GitHub, Bitbucket, ...)
Docker submission:

To submit the docker you should send an email to [email protected] with the link to the git repository with your docker definition.
The docker will then be subjected to a review by our team and we will then contact you with more details.
If you have any question or suggestion regarding this guide please contact us at [email protected].`

Version

No response

Additional Labels

No response

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.