mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Gramar, and spelin kleanup

Browse Source 
A few minor cleanups in various markdown files, mostly focusing on spelling and ignoring non-compilable codeblocks.
This commit is contained in:
Yuri Astrakhan 2023-03-11 18:50:50 -05:00
parent d43714a101
commit 41b367fa5f
21 changed files with 75 additions and 75 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -11,7 +11,7 @@ Lints are divided into categories, each with a default [lint level](https://doc.
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** |
@ -130,7 +130,7 @@ for example.
You can add Clippy to Travis CI in the same way you use it locally:
```yml
```yaml
language: rust
rust:
- stable
@ -253,7 +253,7 @@ rust-version = "1.30"
The MSRV can also be specified as an attribute, like below.
```rust
```rust,ignore
#![feature(custom_inner_attributes)]
#![clippy::msrv = "1.30.0"]

2
book/src/README.md
View File

@ -14,7 +14,7 @@ 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** |

8
book/src/configuration.md
View File

@ -3,7 +3,7 @@
> **Note:** The configuration file is unstable and may be deprecated in the future.
Some lints can be configured in a TOML file named `clippy.toml` or `.clippy.toml`. It contains a
basic `variable = value` mapping eg.
basic `variable = value` mapping e.g.
```toml
avoid-breaking-exported-api = false
@ -60,7 +60,7 @@ 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:
This also works with lint groups. For example, you can run Clippy with warnings for all lints enabled:
```terminal
cargo clippy -- -W clippy::pedantic
@ -84,7 +84,7 @@ msrv = "1.30.0"
The MSRV can also be specified as an attribute, like below.
```rust
```rust,ignore
#![feature(custom_inner_attributes)]
#![clippy::msrv = "1.30.0"]
@ -96,7 +96,7 @@ 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.
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](https://rust-lang.github.io/rust-clippy/master/index.html#msrv)

2
book/src/development/README.md
View File

@ -5,7 +5,7 @@ making Clippy better by contributing to it. In that case, welcome to the
project!
> _Note:_ If you're just interested in using Clippy, there's nothing to see from
> this point onward and you should return to one of the earlier chapters.
> this point onward, and you should return to one of the earlier chapters.
## Getting started

24
book/src/development/adding_lints.md
View File

@ -24,7 +24,7 @@ because that's clearly a non-descriptive name.
- [Lint passes](#lint-passes)
- [Emitting a lint](#emitting-a-lint)
- [Adding the lint logic](#adding-the-lint-logic)
- [Specifying the lint's minimum supported Rust version (MSRV)](#specifying-the-lints-minimum-supported-rust-version-msrv)
- [Specifying the lint's minimum supported Rust version (MSRV)](#specifying-the-lints-minimum-supported-rust-version--msrv-)
- [Author lint](#author-lint)
- [Print HIR lint](#print-hir-lint)
- [Documentation](#documentation)
@ -275,7 +275,7 @@ When declaring a new lint by hand and `cargo dev update_lints` is used, the lint
pass may have to be registered manually in the `register_plugins` function in
`clippy_lints/src/lib.rs`:
```rust
```rust,ignore
store.register_early_pass(|| Box::new(foo_functions::FooFunctions));
```
@ -301,7 +301,7 @@ either [`EarlyLintPass`][early_lint_pass] or [`LateLintPass`][late_lint_pass].
In short, the `LateLintPass` has access to type information while the
`EarlyLintPass` doesn't. If you don't need access to type information, use the
`EarlyLintPass`. The `EarlyLintPass` is also faster. However linting speed
`EarlyLintPass`. The `EarlyLintPass` is also faster. However, linting speed
hasn't really been a concern with Clippy so far.
Since we don't need type information for checking the function name, we used
@ -318,7 +318,7 @@ implementation of the lint logic.
Let's start by implementing the `EarlyLintPass` for our `FooFunctions`:
```rust
```rust,ignore
impl EarlyLintPass for FooFunctions {
fn check_fn(&mut self, cx: &EarlyContext<'_>, fn_kind: FnKind<'_>, span: Span, _: NodeId) {
// TODO: Emit lint here
@ -337,10 +337,10 @@ variety of lint emission functions. They can all be found in
[`clippy_utils/src/diagnostics.rs`][diagnostics].
`span_lint_and_help` seems most appropriate in this case. It allows us to
provide an extra help message and we can't really suggest a better name
provide an extra help message, and we can't really suggest a better name
automatically. This is how it looks:
```rust
```rust,ignore
impl EarlyLintPass for FooFunctions {
fn check_fn(&mut self, cx: &EarlyContext<'_>, fn_kind: FnKind<'_>, span: Span, _: NodeId) {
span_lint_and_help(
@ -479,7 +479,7 @@ the value from `clippy.toml`. This can be accounted for using the
`extract_msrv_attr!(LintContext)` macro and passing
`LateContext`/`EarlyContext`.
```rust
```rust,ignore
impl<'tcx> LateLintPass<'tcx> for ManualStrip {
fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx Expr<'_>) {
...
@ -493,7 +493,7 @@ the lint's test file, `tests/ui/manual_strip.rs` in this example. It should
have a case for the version below the MSRV and one with the same contents but
for the MSRV version itself.
```rust
```rust,ignore
...
#[clippy::msrv = "1.44"]
@ -524,7 +524,7 @@ define_Conf! {
If you have trouble implementing your lint, there is also the internal `author`
lint to generate Clippy code that detects the offending pattern. It does not
work for all of the Rust syntax, but can give a good starting point.
work for all the Rust syntax, but can give a good starting point.
The quickest way to use it, is the [Rust playground:
play.rust-lang.org][author_example]. Put the code you want to lint into the
@ -617,7 +617,7 @@ output in the `stdout` part.
## PR Checklist
Before submitting your PR make sure you followed all of the basic requirements:
Before submitting your PR make sure you followed all the basic requirements:
<!-- Sync this with `.github/PULL_REQUEST_TEMPLATE` -->
@ -637,7 +637,7 @@ for some users. Adding a configuration is done in the following steps:
1. Adding a new configuration entry to [`clippy_lints::utils::conf`] like this:
```rust
```rust,ignore
/// Lint: LINT_NAME.
///
/// <The configuration field doc comment>
@ -690,7 +690,7 @@ for some users. Adding a configuration is done in the following steps:
configuration value is now cloned or copied into a local value that is then
passed to the impl struct like this:
```rust
```rust,ignore
// Default generated registration:
store.register_*_pass(|| box module::StructName);

2
book/src/development/basics.md
View File

@ -125,7 +125,7 @@ We follow a rustc no merge-commit policy. See
## Common Abbreviations
| Abbreviation | Meaning |
| ------------ | -------------------------------------- |
|--------------|----------------------------------------|
| UB | Undefined Behavior |
| FP | False Positive |
| FN | False Negative |

14
book/src/development/common_tools_writing_lints.md
View File

@ -3,7 +3,7 @@
You may need following tooltips to catch up with common operations.
- [Common tools for writing lints](#common-tools-for-writing-lints)
- [Retrieving the type of an expression](#retrieving-the-type-of-an-expression)
- [Retrieving the type of expression](#retrieving-the-type-of-expression)
- [Checking if an expr is calling a specific method](#checking-if-an-expr-is-calling-a-specific-method)
- [Checking for a specific type](#checking-for-a-specific-type)
- [Checking if a type implements a specific trait](#checking-if-a-type-implements-a-specific-trait)
@ -16,7 +16,7 @@ Useful Rustc dev guide links:
- [Type checking](https://rustc-dev-guide.rust-lang.org/type-checking.html)
- [Ty module](https://rustc-dev-guide.rust-lang.org/ty.html)
## Retrieving the type of an expression
## Retrieving the type of expression
Sometimes you may want to retrieve the type `Ty` of an expression `Expr`, for
example to answer following questions:
@ -45,7 +45,7 @@ impl LateLintPass<'_> for MyStructLint {
}
```
Similarly in [`TypeckResults`][TypeckResults] methods, you have the
Similarly, in [`TypeckResults`][TypeckResults] methods, you have the
[`pat_ty()`][pat_ty] method to retrieve a type from a pattern.
Two noticeable items here:
@ -192,7 +192,7 @@ functions to deal with macros:
- `span.from_expansion()`: detects if a span is from macro expansion or
desugaring. Checking this is a common first step in a lint.
```rust
```rust,ignore
if expr.span.from_expansion() {
// just forget it
return;
@ -203,11 +203,11 @@ functions to deal with macros:
if so, which macro call expanded it. It is sometimes useful to check if the
context of two spans are equal.
```rust
```rust,ignore
// expands to `1 + 0`, but don't lint
1 + mac!()
```
```rust
```rust,ignore
if left.span.ctxt() != right.span.ctxt() {
// the coder most likely cannot modify this expression
return;
@ -246,7 +246,7 @@ functions to deal with macros:
`macro_rules!` with `a == $b`, `$b` is expanded to some expression with a
different context from `a`.
```rust
```rust,ignore
macro_rules! m {
($a:expr, $b:expr) => {
if $a.is_some() {

4
book/src/development/infrastructure/book.md
View File

@ -13,7 +13,7 @@ guide to Clippy that you're reading right now. The Clippy book is formatted with
While not strictly necessary since the book source is simply Markdown text
files, having mdBook locally will allow you to build, test and serve the book
locally to view changes before you commit them to the repository. You likely
already have `cargo` installed, so the easiest option is to simply:
already have `cargo` installed, so the easiest option is to:
```shell
cargo install mdbook
@ -26,7 +26,7 @@ instructions for other options.
The book's
[src](https://github.com/rust-lang/rust-clippy/tree/master/book/src)
directory contains all of the markdown files used to generate the book. If you
directory contains all the markdown files used to generate the book. If you
want to see your changes in real time, you can use the mdBook `serve` command to
run a web server locally that will automatically update changes as they are
made. From the top level of your `rust-clippy` directory:

2
book/src/development/infrastructure/changelog_update.md
View File

@ -101,7 +101,7 @@ Look for the [`beta-accepted`] label and make sure to also include the PRs with
that label in the changelog. If you can, remove the `beta-accepted` labels
**after** the changelog PR was merged.
> _Note:_ Some of those PRs might even got backported to the previous `beta`.
> _Note:_ Some of those PRs might even get backported to the previous `beta`.
> Those have to be included in the changelog of the _previous_ release.
### 4. Update `clippy::version` attributes

2
book/src/development/infrastructure/release.md
View File

@ -44,7 +44,7 @@ $ git push origin backport_remerge # This can be pushed to your fork
```
After this, open a PR to the master branch. In this PR, the commit hash of the
`HEAD` of the `beta` branch must exists. In addition to that, no files should be
`HEAD` of the `beta` branch must exist. In addition to that, no files should be
changed by this PR.
## Update the `beta` branch

8
book/src/development/infrastructure/sync.md
View File

@ -47,7 +47,7 @@ sudo chown --reference=/usr/lib/git-core/git-subtree~ /usr/lib/git-core/git-subt
> _Note:_ If you are a Debian user, `dash` is the shell used by default for
> scripts instead of `sh`. This shell has a hardcoded recursion limit set to
> 1000. In order to make this process work, you need to force the script to run
> 1,000. In order to make this process work, you need to force the script to run
> `bash` instead. You can do this by editing the first line of the `git-subtree`
> script and changing `sh` to `bash`.
@ -71,10 +71,10 @@ $ git remote add clippy-local /path/to/rust-clippy
## Performing the sync from [`rust-lang/rust`] to Clippy
Here is a TL;DR version of the sync process (all of the following commands have
Here is a TL;DR version of the sync process (all the following commands have
to be run inside the `rust` directory):
1. Clone the [`rust-lang/rust`] repository or make sure it is up to date.
1. Clone the [`rust-lang/rust`] repository or make sure it is up-to-date.
2. Checkout the commit from the latest available nightly. You can get it using
`rustup check`.
3. Sync the changes to the rust-copy of Clippy to your Clippy fork:
@ -107,7 +107,7 @@ to be run inside the `rust` directory):
## Performing the sync from Clippy to [`rust-lang/rust`]
All of the following commands have to be run inside the `rust` directory.
All the following commands have to be run inside the `rust` directory.
1. Make sure you have checked out the latest `master` of `rust-lang/rust`.
2. Sync the `rust-lang/rust-clippy` master to the rust-copy of Clippy:

2
book/src/development/proposals/README.md
View File

@ -6,6 +6,6 @@ or around Clippy in the long run.
Besides adding more and more lints and improve the lints that Clippy already
has, Clippy is also interested in making the experience of its users, developers
and maintainers better over time. Projects that address bigger picture things
like this usually take more time and it is useful to have a proposal for those
like this usually take more time, and it is useful to have a proposal for those
first. This is the place where such proposals are collected, so that we can
refer to them when working on them.

6
book/src/development/proposals/roadmap-2021.md
View File

@ -52,8 +52,8 @@ In the following, plans to improve the usability are covered.
#### No Output After `cargo check`
Currently when `cargo clippy` is run after `cargo check`, it does not produce
any output. This is especially problematic since `rust-analyzer` is on the rise
Currently, when `cargo clippy` is run after `cargo check`, it does not produce
any output. This is especially problematic since `rust-analyzer` is on the rise,
and it uses `cargo check` for checking code. A fix is already implemented, but
it still has to be pushed over the finish line. This also includes the
stabilization of the `cargo clippy --fix` command or the support of multi-span
@ -221,7 +221,7 @@ regarding the user facing issues.
Rust's roadmap process was established by [RFC 1728] in 2016. Since then every
year a roadmap was published, that defined the bigger plans for the coming
years. This years roadmap can be found [here][Rust Roadmap 2021].
years. This year roadmap can be found [here][Rust Roadmap 2021].
[RFC 1728]: https://rust-lang.github.io/rfcs/1728-north-star.html

28
book/src/development/proposals/syntax-tree-patterns.md
View File

@ -16,7 +16,7 @@ lints. For non-trivial lints, it often requires nested pattern matching of AST /
HIR nodes. For example, testing that an expression is a boolean literal requires
the following checks:
```rust
```rust,ignore
if let ast::ExprKind::Lit(lit) = &expr.node {
if let ast::LitKind::Bool(_) = &lit.node {
...
@ -28,7 +28,7 @@ Writing this kind of matching code quickly becomes a complex task and the
resulting code is often hard to comprehend. The code below shows a simplified
version of the pattern matching required by the `collapsible_if` lint:
```rust
```rust,ignore
// simplified version of the collapsible_if lint
if let ast::ExprKind::If(check, then, None) = &expr.node {
if then.stmts.len() == 1 {
@ -111,7 +111,7 @@ expressions that are boolean literals with value `false`.
The pattern can then be used to implement lints in the following way:
```rust
```rust,ignore
...
impl EarlyLintPass for MyAwesomeLint {
@ -346,7 +346,7 @@ pattern!{
one could get references to the nodes that matched the subpatterns in the
following way:
```rust
```rust,ignore
...
fn check_expr(expr: &syntax::ast::Expr) {
if let Some(result) = my_pattern(expr) {
@ -372,7 +372,7 @@ matches arrays that consist of any number of literal expressions. Because those
expressions are named `foo`, the result struct contains a `foo` attribute which
is a vector of expressions:
```rust
```rust,ignore
...
if let Some(result) = my_pattern_seq(expr) {
result.foo // type: Vec<&syntax::ast::Expr>
@ -394,7 +394,7 @@ In the pattern above, the `bar` name is only defined if the pattern matches a
boolean literal. If it matches an integer literal, the name isn't set. To
account for this, the result struct's `bar` attribute is an option type:
```rust
```rust,ignore
...
if let Some(result) = my_pattern_alt(expr) {
result.bar // type: Option<&bool>
@ -404,7 +404,7 @@ if let Some(result) = my_pattern_alt(expr) {
It's also possible to use a name in multiple alternation branches if they have
compatible types:
```rust
```rust,ignore
pattern!{
// matches if expression is a boolean or integer literal
my_pattern_mult: Expr =
@ -519,7 +519,7 @@ The `Alt`, `Seq` and `Opt` structs look like these:
> Note: The current implementation can be found
> [here](https://github.com/fkohlgrueber/pattern-matching/blob/dfb3bc9fbab69cec7c91e72564a63ebaa2ede638/pattern-match/src/matchers.rs#L35-L60).
```rust
```rust,ignore
pub enum Alt<T> {
Any,
Elmt(Box<T>),
@ -580,7 +580,7 @@ implementations is the `IsMatch` trait. It defines how to match *PatternTree*
nodes against specific syntax tree nodes. A simplified implementation of the
`IsMatch` trait is shown below:
```rust
```rust,ignore
pub trait IsMatch<O> {
fn is_match(&self, other: &'o O) -> bool;
}
@ -619,7 +619,7 @@ approach (matching against the coarse pattern first and checking for additional
properties later) might be slower than the current practice of checking for
structure and additional properties in one pass. For example, the following lint
```rust
```rust,ignore
pattern!{
pat_if_without_else: Expr =
If(
@ -644,7 +644,7 @@ first matches against the pattern and then checks that the `then` block doesn't
start with a comment. Using clippy's current approach, it's possible to check
for these conditions earlier:
```rust
```rust,ignore
fn check_expr(&mut self, cx: &EarlyContext<'_>, expr: &ast::Expr) {
if_chain! {
if let ast::ExprKind::If(ref check, ref then, None) = expr.node;
@ -708,7 +708,7 @@ is similar to actual Rust syntax (probably like the `quote!` macro). For
example, a pattern that matches `if` expressions that have `false` in their
condition could look like this:
```rust
```rust,ignore
if false {
#[*]
}
@ -742,7 +742,7 @@ affects the structure of the resulting AST. `1 + 0 + 0` is parsed as `(1 + 0) +
Another example of a problem would be named submatches. Take a look at this
pattern:
```rust
```rust,ignore
fn test() {
1 #foo
}
@ -862,7 +862,7 @@ op b` and recommends changing it to `a op= b` requires that both occurrences of
`a` are the same. Using `=#...` as syntax for backreferences, the lint could be
implemented like this:
```rust
```rust,ignore
pattern!{
assign_op_pattern: Expr =
Assign(_#target, Binary(_, =#target, _)

4
book/src/installation.md
View File

@ -17,8 +17,8 @@ $ rustup component add clippy [--toolchain=<name>]
## From Source
Take a look at the [Basics] chapter in the Clippy developer guide to find step
by step instructions on how to build and install Clippy from source.
Take a look at the [Basics] chapter in the Clippy developer guide to find step-by-step
instructions on how to build and install Clippy from source.
[Basics]: development/basics.md#install-from-source
[Usage]: usage.md

8
book/src/lint_configuration.md
View File

@ -195,7 +195,7 @@ The maximum cognitive complexity a function can have
### disallowed-names
The list of disallowed names to lint about. NB: `bar` is not here since it has legitimate uses. The value
`".."` can be used as part of the list to indicate, that the configured values should be appended to the
default configuration of Clippy. By default any configuration will replace the default value.
default configuration of Clippy. By default, any configuration will replace the default value.
**Default Value:** `["foo", "baz", "quux"]` (`Vec<String>`)
@ -205,7 +205,7 @@ default configuration of Clippy. By default any configuration will replace the d
### doc-valid-idents
The list of words this lint should not consider as identifiers needing ticks. The value
`".."` can be used as part of the list to indicate, that the configured values should be appended to the
default configuration of Clippy. By default any configuraction will replace the default value. For example:
default configuration of Clippy. By default, any configuration will replace the default value. For example:
* `doc-valid-idents = ["ClipPy"]` would replace the default list with `["ClipPy"]`.
* `doc-valid-idents = ["ClipPy", ".."]` would append `ClipPy` to the default list.
@ -415,7 +415,7 @@ For internal testing only, ignores the current `publish` settings in the Cargo m
Enforce the named macros always use the braces specified.
A `MacroMatcher` can be added like so `{ name = "macro_name", brace = "(" }`. If the macro
is could be used with a full path two `MacroMatcher`s have to be added one with the full path
could be used with a full path two `MacroMatcher`s have to be added one with the full path
`crate_name::macro_name` and one with just the macro name.
**Default Value:** `[]` (`Vec<crate::nonstandard_macro_braces::MacroMatcher>`)
@ -449,7 +449,7 @@ Whether to apply the raw pointer heuristic to determine if a type is `Send`.
### max-suggested-slice-pattern-length
When Clippy suggests using a slice pattern, this is the maximum number of elements allowed in
the slice pattern that is suggested. If more elements would be necessary, the lint is suppressed.
the slice pattern that is suggested. If more elements are necessary, the lint is suppressed.
For example, `[_, _, _, e, ..]` is a slice pattern with 4 elements.
**Default Value:** `3` (`u64`)

10
book/src/lints.md
View File

@ -17,7 +17,7 @@ The different lint groups were defined in the [Clippy 1.0 RFC].
The `clippy::correctness` group is the only lint group in Clippy which lints are
deny-by-default and abort the compilation when triggered. This is for good
reason: If you see a `correctness` lint, it means that your code is outright
wrong or useless and you should try to fix it.
wrong or useless, and you should try to fix it.
Lints in this category are carefully picked and should be free of false
positives. So just `#[allow]`ing those lints is not recommended.
@ -41,7 +41,7 @@ simplify your code. It mostly focuses on code that can be written in a shorter
and more readable way, while preserving the semantics.
If you should see a complexity lint, it usually means that you can remove or
replace some code and it is recommended to do so. However, if you need the more
replace some code, and it is recommended to do so. However, if you need the more
complex code for some expressiveness reason, it is recommended to allow
complexity lints on a case-by-case basis.
@ -50,9 +50,9 @@ complexity lints on a case-by-case basis.
The `clippy::perf` group gives you suggestions on how you can increase the
performance of your code. Those lints are mostly about code that the compiler
can't trivially optimize, but has to be written in a slightly different way to
make the optimizer's job easier.
make the optimizer job easier.
Perf lints are usually easy to apply and it is recommended to do so.
Perf lints are usually easy to apply, and it is recommended to do so.
## Style
@ -91,7 +91,7 @@ and your use case.
Lints from this group will restrict you in some way. If you enable a restriction
lint for your crate it is recommended to also fix code that this lint triggers
on. However, those lints are really strict by design and you might want to
on. However, those lints are really strict by design, and you might want to
`#[allow]` them in some special cases, with a comment justifying that.
## Cargo

4
book/src/usage.md
View File

@ -19,7 +19,7 @@ cargo clippy
### Lint configuration
The above command will run the default set of lints, which are included in the
lint group `clippy::all`. You might want to use even more lints or you might not
lint group `clippy::all`. You might want to use even more lints, or you may not
agree with every Clippy lint, and for that there are ways to configure lint
levels.
@ -98,7 +98,7 @@ other of Clippy's lint groups.
You can configure lint levels in source code the same way you can configure
`rustc` lints:
```rust
```rust,ignore
#![allow(clippy::style)]
#[warn(clippy::double_neg)]

8
clippy_lints/src/utils/conf.rs
View File

@ -275,13 +275,13 @@ pub(crate) fn get_configuration_metadata() -> Vec<ClippyConfiguration> {
///
/// The list of disallowed names to lint about. NB: `bar` is not here since it has legitimate uses. The value
/// `".."` can be used as part of the list to indicate, that the configured values should be appended to the
/// default configuration of Clippy. By default any configuration will replace the default value.
/// default configuration of Clippy. By default, any configuration will replace the default value.
(disallowed_names: Vec<String> = super::DEFAULT_DISALLOWED_NAMES.iter().map(ToString::to_string).collect()),
/// Lint: DOC_MARKDOWN.
///
/// The list of words this lint should not consider as identifiers needing ticks. The value
/// `".."` can be used as part of the list to indicate, that the configured values should be appended to the
/// default configuration of Clippy. By default any configuraction will replace the default value. For example:
/// default configuration of Clippy. By default, any configuration will replace the default value. For example:
/// * `doc-valid-idents = ["ClipPy"]` would replace the default list with `["ClipPy"]`.
/// * `doc-valid-idents = ["ClipPy", ".."]` would append `ClipPy` to the default list.
///
@ -390,7 +390,7 @@ pub(crate) fn get_configuration_metadata() -> Vec<ClippyConfiguration> {
/// Enforce the named macros always use the braces specified.
///
/// A `MacroMatcher` can be added like so `{ name = "macro_name", brace = "(" }`. If the macro
/// is could be used with a full path two `MacroMatcher`s have to be added one with the full path
/// could be used with a full path two `MacroMatcher`s have to be added one with the full path
/// `crate_name::macro_name` and one with just the macro name.
(standard_macro_braces: Vec<crate::nonstandard_macro_braces::MacroMatcher> = Vec::new()),
/// Lint: MISSING_ENFORCED_IMPORT_RENAMES.
@ -408,7 +408,7 @@ pub(crate) fn get_configuration_metadata() -> Vec<ClippyConfiguration> {
/// Lint: INDEX_REFUTABLE_SLICE.
///
/// When Clippy suggests using a slice pattern, this is the maximum number of elements allowed in
/// the slice pattern that is suggested. If more elements would be necessary, the lint is suppressed.
/// the slice pattern that is suggested. If more elements are necessary, the lint is suppressed.
/// For example, `[_, _, _, e, ..]` is a slice pattern with 4 elements.
(max_suggested_slice_pattern_length: u64 = 3),
/// Lint: AWAIT_HOLDING_INVALID_TYPE.

4
etc/relicense/RELICENSE_DOCUMENTATION.md
View File

@ -35,7 +35,7 @@ relicensing are archived on GitHub. We also have saved Wayback Machine copies of
The usernames of commenters on these issues can be found in relicense_comments.txt
There are a couple people in relicense_comments.txt who are not found in contributors.txt:
There are a few people in relicense_comments.txt who are not found in contributors.txt:
- @EpocSquadron has [made minor text contributions to the
README](https://github.com/rust-lang/rust-clippy/commits?author=EpocSquadron) which have since been overwritten, and
@ -55,7 +55,7 @@ There are a couple people in relicense_comments.txt who are not found in contrib
we rewrote (see below)
Two of these contributors had nonminor contributions (#2184, #427) requiring a rewrite, carried out in #3251
Two of these contributors had non-minor contributions (#2184, #427) requiring a rewrite, carried out in #3251
([archive](http://web.archive.org/web/20181005192411/https://github.com/rust-lang-nursery/rust-clippy/pull/3251),
[screenshot](https://user-images.githubusercontent.com/1617736/46573515-5cb69580-c94b-11e8-86e5-b456452121b2.png))

2
lintcheck/README.md
View File

@ -16,7 +16,7 @@ or
cargo lintcheck
```
By default the logs will be saved into
By default, the logs will be saved into
`lintcheck-logs/lintcheck_crates_logs.txt`.
You can set a custom sources.toml by adding `--crates-toml custom.toml` or using