Add "warn/allow by default" to lint descriptions where it was missing.

src/attrs.rs

@@ -8,7 +8,7 @@ use syntax::attr::*;
 use syntax::ast::{Attribute, MetaList, MetaWord};
 use utils::{in_macro, match_path, span_lint, BEGIN_UNWIND};
 
-/// **What it does:** This lint warns on items annotated with `#[inline(always)]`, unless the annotated function is empty or simply panics.
+/// **What it does:** This lint `Warn`s on items annotated with `#[inline(always)]`, unless the annotated function is empty or simply panics.
 ///
 /// **Why is this bad?** While there are valid uses of this annotation (and once you know when to use it, by all means `allow` this lint), it's a common newbie-mistake to pepper one's code with it.
 ///

src/block_in_if_condition.rs

@@ -3,7 +3,7 @@ use rustc::lint::{LateLintPass, LateContext, LintArray, LintPass};
 use rustc_front::intravisit::{Visitor, walk_expr};
 use utils::*;
 
-/// **What it does:** This lint checks for `if` conditions that use blocks to contain an expression.
+/// **What it does:** This lint checks for `if` conditions that use blocks to contain an expression. It is `Warn` by default.
 ///
 /// **Why is this bad?** It isn't really rust style, same as using parentheses to contain expressions.
 ///
@@ -15,7 +15,7 @@ declare_lint! {
     "braces can be eliminated in conditions that are expressions, e.g `if { true } ...`"
 }
 
-/// **What it does:** This lint checks for `if` conditions that use blocks containing statements, or conditions that use closures with blocks.
+/// **What it does:** This lint checks for `if` conditions that use blocks containing statements, or conditions that use closures with blocks. It is `Warn` by default.
 ///
 /// **Why is this bad?** Using blocks in the condition makes it hard to read.
 ///

src/escape.rs

@@ -14,7 +14,7 @@ use utils::span_lint;
 
 pub struct EscapePass;
 
-/// **What it does:** This lint checks for usage of `Box<T>` where an unboxed `T` would work fine
+/// **What it does:** This lint checks for usage of `Box<T>` where an unboxed `T` would work fine. It is `Warn` by default.
 ///
 /// **Why is this bad?** This is an unnecessary allocation, and bad for performance
 ///

src/loops.rs

@@ -50,7 +50,7 @@ declare_lint!{ pub EXPLICIT_ITER_LOOP, Warn,
 declare_lint!{ pub ITER_NEXT_LOOP, Warn,
                "for-looping over `_.next()` which is probably not intended" }
 
-/// **What it does:** This lint detects `loop + match` combinations that are easier written as a `while let` loop.
+/// **What it does:** This lint detects `loop + match` combinations that are easier written as a `while let` loop. It is `Warn` by default.
 ///
 /// **Why is this bad?** The `while let` loop is usually shorter and more readable
 ///
@@ -85,7 +85,7 @@ declare_lint!{ pub UNUSED_COLLECT, Warn,
                "`collect()`ing an iterator without using the result; this is usually better \
                 written as a for loop" }
 
-/// **What it does:** This lint checks for loops over ranges `x..y` where both `x` and `y` are constant and `x` is greater or equal to `y`, unless the range is reversed or has a negative `.step_by(_)`.
+/// **What it does:** This lint checks for loops over ranges `x..y` where both `x` and `y` are constant and `x` is greater or equal to `y`, unless the range is reversed or has a negative `.step_by(_)`. It is `Warn` by default.
 ///
 /// **Why is it bad?** Such loops will either be skipped or loop until wrap-around (in debug code, this may `panic!()`). Both options are probably not intended.
 ///

src/minmax.rs

@@ -8,7 +8,7 @@ use consts::{Constant, constant_simple};
 use utils::{match_def_path, span_lint};
 use self::MinMax::{Min, Max};
 
-/// **What it does:** This lint checks for expressions where `std::cmp::min` and `max` are used to clamp values, but switched so that the result is constant.
+/// **What it does:** This lint checks for expressions where `std::cmp::min` and `max` are used to clamp values, but switched so that the result is constant. It is `Warn` by default.
 ///
 /// **Why is this bad?** This is in all probability not the intended outcome. At the least it hurts readability of the code.
 ///

src/misc.rs

@@ -281,7 +281,7 @@ impl LateLintPass for ModuloOne {
     }
 }
 
-/// **What it does:** This lint checks for patterns in the form `name @ _`.
+/// **What it does:** This lint checks for patterns in the form `name @ _`. It is `Warn` by default.
 ///
 /// **Why is this bad?** It's almost always more readable to just use direct bindings.
 ///

src/mut_reference.rs

@@ -4,7 +4,7 @@ use utils::span_lint;
 use rustc::middle::ty::{TypeAndMut, TypeVariants, MethodCall, TyS};
 use syntax::ptr::P;
 
-/// **What it does:** This lint detects giving a mutable reference to a function that only requires an immutable reference.
+/// **What it does:** This lint detects giving a mutable reference to a function that only requires an immutable reference. It is `Warn` by default.
 ///
 /// **Why is this bad?** The immutable reference rules out all other references to the value. Also the code misleads about the intent of the call site.
 ///

src/strings.rs

@@ -11,7 +11,7 @@ use eq_op::is_exp_equal;
 use utils::{match_type, span_lint, walk_ptrs_ty, get_parent_expr};
 use utils::STRING_PATH;
 
-/// **What it does:** This lint matches code of the form `x = x + y` (without `let`!)
+/// **What it does:** This lint matches code of the form `x = x + y` (without `let`!). It is `Allow` by default.
 ///
 /// **Why is this bad?** Because this expression needs another copy as opposed to `x.push_str(y)` (in practice LLVM will usually elide it, though). Despite [llogiq](https://github.com/llogiq)'s reservations, this lint also is `allow` by default, as some people opine that it's more readable.
 ///

src/types.rs

@@ -17,7 +17,7 @@ use utils::{LL_PATH, VEC_PATH};
 #[allow(missing_copy_implementations)]
 pub struct TypePass;
 
-/// **What it does:** This lint checks for use of `Box<Vec<_>>` anywhere in the code.
+/// **What it does:** This lint checks for use of `Box<Vec<_>>` anywhere in the code. It is `Warn` by default.
 ///
 /// **Why is this bad?** `Vec` already keeps its contents in a separate area on the heap. So if you `Box` it, you just add another level of indirection without any benefit whatsoever.
 ///
@@ -26,7 +26,8 @@ pub struct TypePass;
 /// **Example:** `struct X { values: Box<Vec<Foo>> }`
 declare_lint!(pub BOX_VEC, Warn,
               "usage of `Box<Vec<T>>`, vector elements are already on the heap");
-/// **What it does:** This lint checks for usage of any `LinkedList`, suggesting to use a `Vec` or a `VecDeque` (formerly called `RingBuf`).
+
+/// **What it does:** This lint checks for usage of any `LinkedList`, suggesting to use a `Vec` or a `VecDeque` (formerly called `RingBuf`). It is `Warn` by default.
 ///
 /// **Why is this bad?** Gankro says:
 ///

src/zero_div_zero.rs

@@ -9,7 +9,7 @@ use consts::{Constant, constant_simple, FloatWidth};
 /// 0.0/0.0 with std::f32::NaN or std::f64::NaN, depending on the precision.
 pub struct ZeroDivZeroPass;
 
-/// **What it does:** This lint checks for `0.0 / 0.0`
+/// **What it does:** This lint checks for `0.0 / 0.0`. It is `Warn` by default.
 ///
 /// **Why is this bad?** It's less readable than `std::f32::NAN` or `std::f64::NAN`
 ///