Skip to content

Commit

Permalink
Typo fix in rust-lint-config.md (#4)
Browse files Browse the repository at this point in the history
  • Loading branch information
obi1kenobi authored May 28, 2024
1 parent e1a0519 commit 03ff78e
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion content/rust-lint-config.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ The biggest part of configuring lints is to specify how big a problem it is when

## a secret fourth option

There's another option in `rustc`, though, that is even stricter. If we `forbid` a lint, it's like a stricter version `deny`ing it. There are a [lot of ways](#configuration) to configure lints tools like `rustc` and `clippy`, and sometimes you `deny` a lint (such as the `unsafe-code` lint) at the module level, for example, but you can still `allow` or `warn` an individual `unsafe` block. If we want to prevent this from happening, we can `#![forbid(unsafe_code)]`, and this lint will now _always_ be an error, regardless[^forbid] of other configuration that would otherwise override a `deny` level.
There's another option in `rustc`, though, that is even stricter. If we `forbid` a lint, it's like a stricter version of `deny`ing it. There are a [lot of ways](#configuration) to configure lints tools like `rustc` and `clippy`, and sometimes you `deny` a lint (such as the `unsafe-code` lint) at the module level, for example, but you can still `allow` or `warn` an individual `unsafe` block. If we want to prevent this from happening, we can `#![forbid(unsafe_code)]`, and this lint will now _always_ be an error, regardless[^forbid] of other configuration that would otherwise override a `deny` level.

## a fifth one?

Expand Down

0 comments on commit 03ff78e

Please sign in to comment.