diff --git a/clippy_lints/src/missing_const_for_fn.rs b/clippy_lints/src/missing_const_for_fn.rs
index 2afde0c93..9c9029a50 100644
--- a/clippy_lints/src/missing_const_for_fn.rs
+++ b/clippy_lints/src/missing_const_for_fn.rs
@@ -11,11 +11,11 @@ use syntax_pos::Span;
 
 /// **What it does:**
 ///
-/// Suggests the use of `const` in functions and methods where possible
+/// Suggests the use of `const` in functions and methods where possible.
 ///
 /// **Why is this bad?**
-/// Not using `const` is a missed optimization. Instead of having the function execute at runtime,
-/// when using `const`, it's evaluated at compiletime.
+///
+/// Not having the function const prevents callers of the function from being const as well.
 ///
 /// **Known problems:**
 ///
diff --git a/tests/ui/missing_const_for_fn/could_be_const.rs b/tests/ui/missing_const_for_fn/could_be_const.rs
index 2c0a8e7a3..139e64de1 100644
--- a/tests/ui/missing_const_for_fn/could_be_const.rs
+++ b/tests/ui/missing_const_for_fn/could_be_const.rs
@@ -25,8 +25,8 @@ fn two() -> i32 {
     abc
 }
 
-// TODO: Why can this be const? because it's a zero sized type?
-// There is the `const_string_new` feature, but it seems that this already works in const fns?
+// FIXME: This is a false positive in the `is_min_const_fn` function.
+// At least until the `const_string_new` feature is stabilzed.
 fn string() -> String {
     String::new()
 }
@@ -41,12 +41,14 @@ fn generic<T>(t: T) -> T {
     t
 }
 
-// FIXME: This could be const but is currently not linted
+// FIXME: Depends on the `const_transmute` and `const_fn` feature gates.
+// In the future Clippy should be able to suggest this as const, too.
 fn sub(x: u32) -> usize {
     unsafe { transmute(&x) }
 }
 
-// FIXME: This could be const but is currently not linted
+// NOTE: This is currently not yet allowed to be const
+// Once implemented, Clippy should be able to suggest this as const, too.
 fn generic_arr<T: Copy>(t: [T; 1]) -> T {
     t[0]
 }