Skip to content

Commit 0adb44c

Browse files
committed
---
yaml --- r: 169391 b: refs/heads/master c: 25d5a3a h: refs/heads/master i: 169389: b89a197 169387: 3463587 169383: 97bead9 169375: bfa4918 v: v3
1 parent 796b39e commit 0adb44c

File tree

395 files changed

+9671
-4672
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

395 files changed

+9671
-4672
lines changed

[refs]

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
refs/heads/master: ec7a50d20dff416d9fec837a6492dfe244f5f3ab
2+
refs/heads/master: 25d5a3a19423fee01787de87a56d185dd4e0a4e7
33
refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
44
refs/heads/snap-stage3: 5b3cd3900ceda838f5798c30ab96ceb41f962534
55
refs/heads/try: 5204084bd2e46af7cc6e0147430e44dd0d657bbb

trunk/mk/docs.mk

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -49,8 +49,10 @@ RUSTDOC_HTML_OPTS_NO_CSS = --html-before-content=doc/version_info.html \
4949
RUSTDOC_HTML_OPTS = $(RUSTDOC_HTML_OPTS_NO_CSS) --markdown-css rust.css
5050

5151
PANDOC_BASE_OPTS := --standalone --toc --number-sections
52-
PANDOC_TEX_OPTS = $(PANDOC_BASE_OPTS) --include-before-body=doc/version.tex \
53-
--from=markdown --include-before-body=doc/footer.tex --to=latex
52+
PANDOC_TEX_OPTS = $(PANDOC_BASE_OPTS) --from=markdown --to=latex \
53+
--include-before-body=doc/version.tex \
54+
--include-before-body=doc/footer.tex \
55+
--include-in-header=doc/uptack.tex
5456
PANDOC_EPUB_OPTS = $(PANDOC_BASE_OPTS) --to=epub
5557

5658
# The rustdoc executable...
@@ -155,6 +157,9 @@ doc/footer.tex: $(D)/footer.inc | doc/
155157
@$(call E, pandoc: $@)
156158
$(CFG_PANDOC) --from=html --to=latex $< --output=$@
157159

160+
doc/uptack.tex: $(D)/uptack.tex | doc/
161+
$(Q)cp $< $@
162+
158163
# HTML (rustdoc)
159164
DOC_TARGETS += doc/not_found.html
160165
doc/not_found.html: $(D)/not_found.md $(HTML_DEPS) | doc/
@@ -180,7 +185,7 @@ doc/$(1).epub: $$(D)/$(1).md | doc/
180185

181186
# PDF (md =(pandoc)=> tex =(pdflatex)=> pdf)
182187
DOC_TARGETS += doc/$(1).tex
183-
doc/$(1).tex: $$(D)/$(1).md doc/footer.tex doc/version.tex | doc/
188+
doc/$(1).tex: $$(D)/$(1).md doc/uptack.tex doc/footer.tex doc/version.tex | doc/
184189
@$$(call E, pandoc: $$@)
185190
$$(CFG_PANDOC) $$(PANDOC_TEX_OPTS) $$< --output=$$@
186191

trunk/src/compiletest/compiletest.rs

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -339,8 +339,9 @@ pub fn is_test(config: &Config, testfile: &Path) -> bool {
339339
return valid;
340340
}
341341

342-
pub fn make_test(config: &Config, testfile: &Path, f: || -> test::TestFn)
343-
-> test::TestDescAndFn {
342+
pub fn make_test<F>(config: &Config, testfile: &Path, f: F) -> test::TestDescAndFn where
343+
F: FnOnce() -> test::TestFn,
344+
{
344345
test::TestDescAndFn {
345346
desc: test::TestDesc {
346347
name: make_test_name(config, testfile),

trunk/src/compiletest/header.rs

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -220,7 +220,9 @@ pub fn is_test_ignored(config: &Config, testfile: &Path) -> bool {
220220
!val
221221
}
222222

223-
fn iter_header(testfile: &Path, it: |&str| -> bool) -> bool {
223+
fn iter_header<F>(testfile: &Path, mut it: F) -> bool where
224+
F: FnMut(&str) -> bool,
225+
{
224226
use std::io::{BufferedReader, File};
225227

226228
let mut rdr = BufferedReader::new(File::open(testfile).unwrap());

trunk/src/compiletest/runtest.rs

Lines changed: 8 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1233,12 +1233,14 @@ enum TargetLocation {
12331233
ThisDirectory(Path),
12341234
}
12351235

1236-
fn make_compile_args(config: &Config,
1237-
props: &TestProps,
1238-
extras: Vec<String> ,
1239-
xform: |&Config, &Path| -> TargetLocation,
1240-
testfile: &Path)
1241-
-> ProcArgs {
1236+
fn make_compile_args<F>(config: &Config,
1237+
props: &TestProps,
1238+
extras: Vec<String> ,
1239+
xform: F,
1240+
testfile: &Path)
1241+
-> ProcArgs where
1242+
F: FnOnce(&Config, &Path) -> TargetLocation,
1243+
{
12421244
let xform_file = xform(config, testfile);
12431245
let target = if props.force_host {
12441246
config.host.as_slice()

trunk/src/doc/complement-lang-faq.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@ Some examples that demonstrate different aspects of the language:
1717
* [sprocketnes], an NES emulator with no GC, using modern Rust conventions
1818
* The language's general-purpose [hash] function, SipHash-2-4. Bit twiddling, OO, macros
1919
* The standard library's [HashMap], a sendable hash map in an OO style
20-
* The extra library's [json] module. Enums and pattern matching
20+
* The standard library's [json] module. Enums and pattern matching
2121

2222
[sprocketnes]: https://github.com/pcwalton/sprocketnes
2323
[hash]: https://github.com/rust-lang/rust/blob/master/src/libstd/hash/mod.rs

trunk/src/doc/guide-ownership.md

Lines changed: 77 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -230,8 +230,9 @@ fn add_one(num: &int) -> int {
230230
```
231231

232232
Rust has a feature called 'lifetime elision,' which allows you to not write
233-
lifetime annotations in certain circumstances. This is one of them. Without
234-
eliding the lifetimes, `add_one` looks like this:
233+
lifetime annotations in certain circumstances. This is one of them. We will
234+
cover the others later. Without eliding the lifetimes, `add_one` looks like
235+
this:
235236

236237
```rust
237238
fn add_one<'a>(num: &'a int) -> int {
@@ -449,6 +450,80 @@ This is the simplest kind of multiple ownership possible. For example, there's
449450
also `Arc<T>`, which uses more expensive atomic instructions to be the
450451
thread-safe counterpart of `Rc<T>`.
451452

453+
## Lifetime Elision
454+
455+
Earlier, we mentioned 'lifetime elision,' a feature of Rust which allows you to
456+
not write lifetime annotations in certain circumstances. All references have a
457+
lifetime, and so if you elide a lifetime (like `&T` instead of `&'a T`), Rust
458+
will do three things to determine what those lifetimes should be.
459+
460+
When talking about lifetime elision, we use the term 'input lifetime' and
461+
'output lifetime'. An 'input liftime' is a lifetime associated with a parameter
462+
of a function, and an 'output lifetime' is a lifetime associated with the return
463+
value of a function. For example, this function has an input lifetime:
464+
465+
```{rust,ignore}
466+
fn foo<'a>(bar: &'a str)
467+
```
468+
469+
This one has an output lifetime:
470+
471+
```{rust,ignore}
472+
fn foo<'a>() -> &'a str
473+
```
474+
475+
This one has a lifetime in both positions:
476+
477+
```{rust,ignore}
478+
fn foo<'a>(bar: &'a str) -> &'a str
479+
```
480+
481+
Here are the three rules:
482+
483+
* Each elided lifetime in a function's arguments becomes a distinct lifetime
484+
parameter.
485+
486+
* If there is exactly one input lifetime, elided or not, that lifetime is
487+
assigned to all elided lifetimes in the return values of that function..
488+
489+
* If there are multiple input lifetimes, but one of them is `&self` or `&mut
490+
self`, the lifetime of `self` is assigned to all elided output lifetimes.
491+
492+
Otherwise, it is an error to elide an output lifetime.
493+
494+
### Examples
495+
496+
Here are some examples of functions with elided lifetimes, and the version of
497+
what the elided lifetimes are expand to:
498+
499+
```{rust,ignore}
500+
fn print(s: &str); // elided
501+
fn print<'a>(s: &'a str); // expanded
502+
503+
fn debug(lvl: uint, s: &str); // elided
504+
fn debug<'a>(lvl: uint, s: &'a str); // expanded
505+
506+
// In the preceeding example, `lvl` doesn't need a lifetime because it's not a
507+
// reference (`&`). Only things relating to references (such as a `struct`
508+
// which contains a reference) need lifetimes.
509+
510+
fn substr(s: &str, until: uint) -> &str; // elided
511+
fn substr<'a>(s: &'a str, until: uint) -> &'a str; // expanded
512+
513+
fn get_str() -> &str; // ILLEGAL, no inputs
514+
515+
fn frob(s: &str, t: &str) -> &str; // ILLEGAL, two inputs
516+
517+
fn get_mut(&mut self) -> &mut T; // elided
518+
fn get_mut<'a>(&'a mut self) -> &'a mut T; // expanded
519+
520+
fn args<T:ToCStr>(&mut self, args: &[T]) -> &mut Command // elided
521+
fn args<'a, 'b, T:ToCStr>(&'a mut self, args: &'b [T]) -> &'a mut Command // expanded
522+
523+
fn new(buf: &mut [u8]) -> BufWriter; // elided
524+
fn new<'a>(buf: &'a mut [u8]) -> BufWriter<'a> // expanded
525+
```
526+
452527
# Related Resources
453528

454529
Coming Soon.

trunk/src/doc/guide-testing.md

Lines changed: 15 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -503,6 +503,8 @@ Advice on writing benchmarks:
503503
* Make the code in the `iter` loop do something simple, to assist in pinpointing
504504
performance improvements (or regressions)
505505

506+
## Gotcha: optimizations
507+
506508
There's another tricky part to writing benchmarks: benchmarks compiled with
507509
optimizations activated can be dramatically changed by the optimizer so that
508510
the benchmark is no longer benchmarking what one expects. For example, the
@@ -537,7 +539,8 @@ computation entirely. This could be done for the example above by adjusting the
537539
`b.iter` call to
538540

539541
```rust
540-
# struct X; impl X { fn iter<T>(&self, _: || -> T) {} } let b = X;
542+
# struct X;
543+
# impl X { fn iter<T, F>(&self, _: F) where F: FnMut() -> T {} } let b = X;
541544
b.iter(|| {
542545
// note lack of `;` (could also use an explicit `return`).
543546
range(0u, 1000).fold(0, |old, new| old ^ new)
@@ -552,10 +555,15 @@ argument as used.
552555
extern crate test;
553556

554557
# fn main() {
555-
# struct X; impl X { fn iter<T>(&self, _: || -> T) {} } let b = X;
558+
# struct X;
559+
# impl X { fn iter<T, F>(&self, _: F) where F: FnMut() -> T {} } let b = X;
556560
b.iter(|| {
557-
test::black_box(range(0u, 1000).fold(0, |old, new| old ^ new));
558-
});
561+
let mut n = 1000_u32;
562+
563+
test::black_box(&mut n); // pretend to modify `n`
564+
565+
range(0, n).fold(0, |a, b| a ^ b)
566+
})
559567
# }
560568
```
561569

@@ -571,3 +579,6 @@ test bench_xor_1000_ints ... bench: 1 ns/iter (+/- 0)
571579
572580
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured
573581
```
582+
583+
However, the optimizer can still modify a testcase in an undesirable manner
584+
even when using either of the above.

trunk/src/doc/guide.md

Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -355,7 +355,7 @@ Hello, world!
355355
Bam! We build our project with `cargo build`, and run it with
356356
`./target/hello_world`. This hasn't bought us a whole lot over our simple use
357357
of `rustc`, but think about the future: when our project has more than one
358-
file, we would need to call `rustc` twice, and pass it a bunch of options to
358+
file, we would need to call `rustc` more than once, and pass it a bunch of options to
359359
tell it to build everything together. With Cargo, as our project grows, we can
360360
just `cargo build` and it'll work the right way.
361361

@@ -977,7 +977,7 @@ fn main() {
977977
```
978978

979979
Even though Rust functions can only return one value, a tuple _is_ one value,
980-
that happens to be made up of two. You can also see in this example how you
980+
that happens to be made up of more than one value. You can also see in this example how you
981981
can destructure a pattern returned by a function, as well.
982982

983983
Tuples are a very simple data structure, and so are not often what you want.
@@ -4232,7 +4232,7 @@ arguments, really powerful things are possible.
42324232
Let's make a closure:
42334233
42344234
```{rust}
4235-
let add_one = |x| { 1 + x };
4235+
let add_one = |&: x| { 1 + x };
42364236
42374237
println!("The sum of 5 plus 1 is {}.", add_one(5));
42384238
```
@@ -4244,8 +4244,8 @@ binding name and two parentheses, just like we would for a named function.
42444244
Let's compare syntax. The two are pretty close:
42454245
42464246
```{rust}
4247-
let add_one = |x: i32| -> i32 { 1 + x };
4248-
fn add_one (x: i32) -> i32 { 1 + x }
4247+
let add_one = |&: x: i32| -> i32 { 1 + x };
4248+
fn add_one (x: i32) -> i32 { 1 + x }
42494249
```
42504250
42514251
As you may have noticed, closures infer their argument and return types, so you
@@ -4258,9 +4258,9 @@ this:
42584258
42594259
```{rust}
42604260
fn main() {
4261-
let x = 5;
4261+
let x: i32 = 5;
42624262
4263-
let printer = || { println!("x is: {}", x); };
4263+
let printer = |&:| { println!("x is: {}", x); };
42644264
42654265
printer(); // prints "x is: 5"
42664266
}
@@ -4276,7 +4276,7 @@ defined. The closure borrows any variables it uses, so this will error:
42764276
fn main() {
42774277
let mut x = 5;
42784278
4279-
let printer = || { println!("x is: {}", x); };
4279+
let printer = |&:| { println!("x is: {}", x); };
42804280
42814281
x = 6; // error: cannot assign to `x` because it is borrowed
42824282
}
@@ -4298,12 +4298,12 @@ now. We'll talk about them more in the "Threads" section of the guide.
42984298
Closures are most useful as an argument to another function. Here's an example:
42994299
43004300
```{rust}
4301-
fn twice(x: i32, f: |i32| -> i32) -> i32 {
4301+
fn twice<F: Fn(i32) -> i32>(x: i32, f: F) -> i32 {
43024302
f(x) + f(x)
43034303
}
43044304
43054305
fn main() {
4306-
let square = |x: i32| { x * x };
4306+
let square = |&: x: i32| { x * x };
43074307
43084308
twice(5, square); // evaluates to 50
43094309
}
@@ -4312,15 +4312,15 @@ fn main() {
43124312
Let's break the example down, starting with `main`:
43134313
43144314
```{rust}
4315-
let square = |x: i32| { x * x };
4315+
let square = |&: x: i32| { x * x };
43164316
```
43174317
43184318
We've seen this before. We make a closure that takes an integer, and returns
43194319
its square.
43204320
43214321
```{rust}
4322-
# fn twice(x: i32, f: |i32| -> i32) -> i32 { f(x) + f(x) }
4323-
# let square = |x: i32| { x * x };
4322+
# fn twice<F: Fn(i32) -> i32>(x: i32, f: F) -> i32 { f(x) + f(x) }
4323+
# let square = |&: x: i32| { x * x };
43244324
twice(5, square); // evaluates to 50
43254325
```
43264326
@@ -4343,8 +4343,8 @@ how the `|i32| -> i32` syntax looks a lot like our definition of `square`
43434343
above, if we added the return type in:
43444344
43454345
```{rust}
4346-
let square = |x: i32| -> i32 { x * x };
4347-
// |i32| -> i32
4346+
let square = |&: x: i32| -> i32 { x * x };
4347+
// |i32| -> i32
43484348
```
43494349
43504350
This function takes an `i32` and returns an `i32`.
@@ -4358,7 +4358,7 @@ Finally, `twice` returns an `i32` as well.
43584358
Okay, let's look at the body of `twice`:
43594359
43604360
```{rust}
4361-
fn twice(x: i32, f: |i32| -> i32) -> i32 {
4361+
fn twice<F: Fn(i32) -> i32>(x: i32, f: F) -> i32 {
43624362
f(x) + f(x)
43634363
}
43644364
```
@@ -4376,7 +4376,7 @@ If we didn't want to give `square` a name, we could just define it inline.
43764376
This example is the same as the previous one:
43774377
43784378
```{rust}
4379-
fn twice(x: i32, f: |i32| -> i32) -> i32 {
4379+
fn twice<F: Fn(i32) -> i32>(x: i32, f: F) -> i32 {
43804380
f(x) + f(x)
43814381
}
43824382
@@ -4389,7 +4389,7 @@ A named function's name can be used wherever you'd use a closure. Another
43894389
way of writing the previous example:
43904390
43914391
```{rust}
4392-
fn twice(x: i32, f: |i32| -> i32) -> i32 {
4392+
fn twice<F: Fn(i32) -> i32>(x: i32, f: F) -> i32 {
43934393
f(x) + f(x)
43944394
}
43954395

0 commit comments

Comments
 (0)