Merge remote-tracking branch 'upstream/master' into rustup

3 files changed, 61 insertions, 2 deletions

diff --git a/src/docs/arithmetic_side_effects.txt b/src/docs/arithmetic_side_effects.txt
index 6c7d51a4989..b8c0872522e 100644
--- a/src/docs/arithmetic_side_effects.txt
+++ b/src/docs/arithmetic_side_effects.txt
@@ -5,7 +5,7 @@ Operators like `+`, `-`, `*` or `<<` are usually capable of overflowing accordin
 Reference](https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow),
 or can panic (`/`, `%`).
 
-Known safe built-in types like `Wrapping` or `Saturing`, floats, operations in constant
+Known safe built-in types like `Wrapping` or `Saturating`, floats, operations in constant
 environments, allowed types and non-constant operations that won't overflow are ignored.
 
 ### Why is this bad?
@@ -30,4 +30,4 @@ let _n = Decimal::MAX + Decimal::MAX;
 ```
 
 ### Allowed types
-Custom allowed types can be specified through the "arithmetic-side-effects-allowed" filter.
\ No newline at end of file
+Custom allowed types can be specified through the "arithmetic-side-effects-allowed" filter.
diff --git a/src/docs/box_default.txt b/src/docs/box_default.txt
new file mode 100644
index 00000000000..ffac894d0c5
--- /dev/null
+++ b/src/docs/box_default.txt
@@ -0,0 +1,23 @@
+### What it does
+checks for `Box::new(T::default())`, which is better written as
+`Box::<T>::default()`.
+
+### Why is this bad?
+First, it's more complex, involving two calls instead of one.
+Second, `Box::default()` can be faster
+[in certain cases](https://nnethercote.github.io/perf-book/standard-library-types.html#box).
+
+### Known problems
+The lint may miss some cases (e.g. Box::new(String::from(""))).
+On the other hand, it will trigger on cases where the `default`
+code comes from a macro that does something different based on
+e.g. target operating system.
+
+### Example
+```
+let x: Box<String> = Box::new(Default::default());
+```
+Use instead:
+```
+let x: Box<String> = Box::default();
+```
\ No newline at end of file
diff --git a/src/docs/uninlined_format_args.txt b/src/docs/uninlined_format_args.txt
new file mode 100644
index 00000000000..3d2966c84db
--- /dev/null
+++ b/src/docs/uninlined_format_args.txt
@@ -0,0 +1,36 @@
+### What it does
+Detect when a variable is not inlined in a format string,
+and suggests to inline it.
+
+### Why is this bad?
+Non-inlined code is slightly more difficult to read and understand,
+as it requires arguments to be matched against the format string.
+The inlined syntax, where allowed, is simpler.
+
+### Example
+```
+format!("{}", var);
+format!("{v:?}", v = var);
+format!("{0} {0}", var);
+format!("{0:1$}", var, width);
+format!("{:.*}", prec, var);
+```
+Use instead:
+```
+format!("{var}");
+format!("{var:?}");
+format!("{var} {var}");
+format!("{var:width$}");
+format!("{var:.prec$}");
+```
+
+### Known Problems
+
+There may be a false positive if the format string is expanded from certain proc macros:
+
+```
+println!(indoc!("{}"), var);
+```
+
+If a format string contains a numbered argument that cannot be inlined
+nothing will be suggested, e.g. `println!("{0}={1}", var, 1+2)`.
\ No newline at end of file