Skip to content

Commit d8e5d27

Browse files
committed
auto merge of #13920 : Ryman/rust/inner_attr_doc, r=alexcrichton
Also updated the comment for `parse_inner_attrs_and_next` and removed extra whitespace on line endings.
2 parents 922c420 + 7439224 commit d8e5d27

File tree

2 files changed

+8
-7
lines changed

2 files changed

+8
-7
lines changed

src/doc/guide-pointers.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -186,7 +186,7 @@ enum List<T> {
186186
Nil,
187187
Cons(T, ~List<T>),
188188
}
189-
189+
190190
fn main() {
191191
let list: List<int> = Cons(1, ~Cons(2, ~Cons(3, ~Nil)));
192192
println!("{:?}", list);
@@ -251,7 +251,7 @@ struct.
251251

252252
> **Note**: the `@` form of managed pointers is deprecated and behind a
253253
> feature gate (it requires a `#![feature(managed_pointers)]` attribute on
254-
> the crate root; remember the semicolon!). There are replacements, currently
254+
> the crate root). There are replacements, currently
255255
> there is `std::rc::Rc` and `std::gc::Gc` for shared ownership via reference
256256
> counting and garbage collection respectively.
257257
@@ -266,7 +266,7 @@ struct Point {
266266
x: int,
267267
y: int,
268268
}
269-
269+
270270
fn main() {
271271
let a = ~Point { x: 10, y: 20 };
272272
let b = a;
@@ -297,7 +297,7 @@ struct Point {
297297
x: int,
298298
y: int,
299299
}
300-
300+
301301
fn main() {
302302
let a = @Point { x: 10, y: 20 };
303303
let b = a;
@@ -361,7 +361,7 @@ So how is this hard? Well, because we're ignoring ownership, the compiler needs
361361
to take great care to make sure that everything is safe. Despite their complete
362362
safety, a reference's representation at runtime is the same as that of
363363
an ordinary pointer in a C program. They introduce zero overhead. The compiler
364-
does all safety checks at compile time.
364+
does all safety checks at compile time.
365365

366366
This theory is called 'region pointers,' and involve a concept called
367367
'lifetimes'. Here's the simple explanation: would you expect this code to
@@ -477,7 +477,7 @@ fn main() {
477477
You may think that this gives us terrible performance: return a value and then
478478
immediately box it up?!?! Isn't that the worst of both worlds? Rust is smarter
479479
than that. There is no copy in this code. `main` allocates enough room for the
480-
`@int`, passes a pointer to that memory into `foo` as `x`, and then `foo` writes
480+
`@int`, passes a pointer to that memory into `foo` as `x`, and then `foo` writes
481481
the value straight into that pointer. This writes the return value directly into
482482
the allocated box.
483483

src/libsyntax/parse/attr.rs

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -108,7 +108,8 @@ impl<'a> ParserAttr for Parser<'a> {
108108
};
109109
}
110110

111-
// Parse attributes that appear after the opening of an item, each
111+
// Parse attributes that appear after the opening of an item. These should
112+
// be preceded by an exclaimation mark, but we accept and warn about one
112113
// terminated by a semicolon. In addition to a vector of inner attributes,
113114
// this function also returns a vector that may contain the first outer
114115
// attribute of the next item (since we can't know whether the attribute

0 commit comments

Comments
 (0)