From 74392246ff1dc6f0d9b5601eda661c7f02f18ba1 Mon Sep 17 00:00:00 2001
From: Kevin Butler <haqkrs@gmail.com>
Date: Sat, 3 May 2014 21:24:06 +0100
Subject: [PATCH] Remove comment about semicolons for inner attributes from
 docs and adjust comments.

---
 src/doc/guide-pointers.md   | 12 ++++++------
 src/libsyntax/parse/attr.rs |  3 ++-
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/doc/guide-pointers.md b/src/doc/guide-pointers.md
index 9780a12a402..fa813073cd9 100644
--- a/src/doc/guide-pointers.md
+++ b/src/doc/guide-pointers.md
@@ -186,7 +186,7 @@ enum List<T> {
     Nil,
     Cons(T, ~List<T>),
 }
-    
+
 fn main() {
     let list: List<int> = Cons(1, ~Cons(2, ~Cons(3, ~Nil)));
     println!("{:?}", list);
@@ -251,7 +251,7 @@ struct.
 
 > **Note**: the `@` form of managed pointers is deprecated and behind a
 > feature gate (it requires a `#![feature(managed_pointers)]` attribute on
-> the crate root; remember the semicolon!). There are replacements, currently 
+> the crate root). There are replacements, currently
 > there is `std::rc::Rc` and `std::gc::Gc` for shared ownership via reference
 > counting and garbage collection respectively.
 
@@ -266,7 +266,7 @@ struct Point {
     x: int,
     y: int,
 }
-    
+
 fn main() {
     let a = ~Point { x: 10, y: 20 };
     let b = a;
@@ -297,7 +297,7 @@ struct Point {
     x: int,
     y: int,
 }
-    
+
 fn main() {
     let a = @Point { x: 10, y: 20 };
     let b = a;
@@ -361,7 +361,7 @@ So how is this hard? Well, because we're ignoring ownership, the compiler needs
 to take great care to make sure that everything is safe. Despite their complete
 safety, a reference's representation at runtime is the same as that of
 an ordinary pointer in a C program. They introduce zero overhead. The compiler
-does all safety checks at compile time. 
+does all safety checks at compile time.
 
 This theory is called 'region pointers,' and involve a concept called
 'lifetimes'. Here's the simple explanation: would you expect this code to
@@ -477,7 +477,7 @@ fn main() {
 You may think that this gives us terrible performance: return a value and then
 immediately box it up?!?! Isn't that the worst of both worlds? Rust is smarter
 than that. There is no copy in this code. `main` allocates enough room for the
-`@int`, passes a pointer to that memory into `foo` as `x`, and then `foo` writes 
+`@int`, passes a pointer to that memory into `foo` as `x`, and then `foo` writes
 the value straight into that pointer. This writes the return value directly into
 the allocated box.
 
diff --git a/src/libsyntax/parse/attr.rs b/src/libsyntax/parse/attr.rs
index ddb6ddb64b4..80ee459a62d 100644
--- a/src/libsyntax/parse/attr.rs
+++ b/src/libsyntax/parse/attr.rs
@@ -108,7 +108,8 @@ impl<'a> ParserAttr for Parser<'a> {
         };
     }
 
-    // Parse attributes that appear after the opening of an item, each
+    // Parse attributes that appear after the opening of an item. These should
+    // be preceded by an exclaimation mark, but we accept and warn about one
     // terminated by a semicolon. In addition to a vector of inner attributes,
     // this function also returns a vector that may contain the first outer
     // attribute of the next item (since we can't know whether the attribute