Remove redundancy in lint documentation

The default level is always given in the declare_lint! macro, no need to
add it inconsistently in the documentation.

src/methods.rs

@@ -18,7 +18,7 @@ use rustc::middle::cstore::CrateStore;
 #[derive(Clone)]
 pub struct MethodsPass;
 
-/// **What it does:** This lint checks for `.unwrap()` calls on `Option`s. It is `Allow` by default.
+/// **What it does:** This lint checks for `.unwrap()` calls on `Option`s.
 ///
 /// **Why is this bad?** Usually it is better to handle the `None` case, or to at least call `.expect(_)` with a more helpful message. Still, for a lot of quick-and-dirty code, `unwrap` is a good choice, which is why this lint is `Allow` by default.
 ///
@@ -30,7 +30,7 @@ declare_lint! {
     "using `Option.unwrap()`, which should at least get a better message using `expect()`"
 }
 
-/// **What it does:** This lint checks for `.unwrap()` calls on `Result`s. It is `Allow` by default.
+/// **What it does:** This lint checks for `.unwrap()` calls on `Result`s.
 ///
 /// **Why is this bad?** `result.unwrap()` will let the thread panic on `Err` values. Normally, you want to implement more sophisticated error handling, and propagate errors upwards with `try!`.
 ///
@@ -44,7 +44,7 @@ declare_lint! {
     "using `Result.unwrap()`, which might be better handled"
 }
 
-/// **What it does:** This lint checks for `.to_string()` method calls on values of type `&str`. It is `Warn` by default.
+/// **What it does:** This lint checks for `.to_string()` method calls on values of type `&str`.
 ///
 /// **Why is this bad?** This uses the whole formatting machinery just to clone a string. Using `.to_owned()` is lighter on resources. You can also consider using a [`Cow<'a, str>`](http://doc.rust-lang.org/std/borrow/enum.Cow.html) instead in some cases.
 ///
@@ -56,7 +56,7 @@ declare_lint! {
     "using `to_string()` on a str, which should be `to_owned()`"
 }
 
-/// **What it does:** This lint checks for `.to_string()` method calls on values of type `String`. It is `Warn` by default.
+/// **What it does:** This lint checks for `.to_string()` method calls on values of type `String`.
 ///
 /// **Why is this bad?** This is an non-efficient way to clone a `String`, `.clone()` should be used
 /// instead. `String` implements `ToString` mostly for generics.
@@ -69,7 +69,7 @@ declare_lint! {
     "calling `String::to_string` which is inefficient"
 }
 
-/// **What it does:** This lint checks for methods that should live in a trait implementation of a `std` trait (see [llogiq's blog post](http://llogiq.github.io/2015/07/30/traits.html) for further information) instead of an inherent implementation. It is `Warn` by default.
+/// **What it does:** This lint checks for methods that should live in a trait implementation of a `std` trait (see [llogiq's blog post](http://llogiq.github.io/2015/07/30/traits.html) for further information) instead of an inherent implementation.
 ///
 /// **Why is this bad?** Implementing the traits improve ergonomics for users of the code, often with very little cost. Also people seeing a `mul(..)` method may expect `*` to work equally, so you should have good reason to disappoint them.
 ///
@@ -87,7 +87,7 @@ declare_lint! {
     "defining a method that should be implementing a std trait"
 }
 
-/// **What it does:** This lint checks for methods with certain name prefixes and `Warn`s (by default) if the prefix doesn't match how self is taken. The actual rules are:
+/// **What it does:** This lint checks for methods with certain name prefixes and which doesn't match how self is taken. The actual rules are:
 ///
 /// |Prefix |`self` taken        |
 /// |-------|--------------------|
@@ -97,7 +97,7 @@ declare_lint! {
 /// |`is_`  |`&self` or none     |
 /// |`to_`  |`&self`             |
 ///
-/// **Why is this bad?** Consistency breeds readability. If you follow the conventions, your users won't be surprised that they e.g. need to supply a mutable reference to a `as_`.. function.
+/// **Why is this bad?** Consistency breeds readability. If you follow the conventions, your users won't be surprised that they e.g. need to supply a mutable reference to a `as_..` function.
 ///
 /// **Known problems:** None
 ///
@@ -114,7 +114,7 @@ declare_lint! {
      `self` with the wrong convention"
 }
 
-/// **What it does:** This is the same as [`wrong_self_convention`](#wrong_self_convention), but for public items. This lint is `Allow` by default.
+/// **What it does:** This is the same as [`wrong_self_convention`](#wrong_self_convention), but for public items.
 ///
 /// **Why is this bad?** See [`wrong_self_convention`](#wrong_self_convention).
 ///
@@ -132,7 +132,7 @@ declare_lint! {
      `self` with the wrong convention"
 }
 
-/// **What it does:** This lint `Warn`s on using `ok().expect(..)`.
+/// **What it does:** This lint checks for usage of `ok().expect(..)`.
 ///
 /// **Why is this bad?** Because you usually call `expect()` on the `Result` directly to get a good error message.
 ///
@@ -145,7 +145,7 @@ declare_lint! {
      calling `expect` directly on the Result"
 }
 
-/// **What it does:** This lint `Warn`s on `_.map(_).unwrap_or(_)`.
+/// **What it does:** This lint checks for usage of `_.map(_).unwrap_or(_)`.
 ///
 /// **Why is this bad?** Readability, this can be written more concisely as `_.map_or(_, _)`.
 ///
@@ -234,7 +234,7 @@ declare_lint! {
     "using any `*or` method when the `*or_else` would do"
 }
 
-/// **What it does:** This lint `Warn`s on using `.extend(s)` on a `vec` to extend the vec by a slice.
+/// **What it does:** This lint checks for usage of `.extend(s)` on a `Vec` to extend the vector by a slice.
 ///
 /// **Why is this bad?** Since Rust 1.6, the `extend_from_slice(_)` method is stable and at least for now faster.
 ///