Skip to content

Commit 0b96d76

Browse files
committed
---
yaml --- r: 97535 b: refs/heads/snap-stage3 c: e4804ac h: refs/heads/master i: 97533: c852848 97531: 32be235 97527: 6f1bd0c 97519: c968e48 97503: 1a57f28 97471: ad92b42 97407: f6db5ed 97279: 7bba6be v: v3
1 parent 7cf377a commit 0b96d76

Some content is hidden

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

66 files changed

+514
-964
lines changed

[refs]

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
refs/heads/master: 0da105a8b7b6b1e0568e8ff20f6ff4b13cc7ecc2
33
refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
4-
refs/heads/snap-stage3: f3a8baafbecdb6e41f001c8f218d4796a9ca8d40
4+
refs/heads/snap-stage3: e4804acaca044782e65646e76f3f765d97c74615
55
refs/heads/try: c274a6888410ce3e357e014568b43310ed787d36
66
refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
77
refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b

branches/snap-stage3/Makefile.in

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -410,7 +410,6 @@ export CFG_SRC_DIR
410410
export CFG_BUILD_DIR
411411
export CFG_VERSION
412412
export CFG_VERSION_WIN
413-
export CFG_RELEASE
414413
export CFG_BUILD
415414
export CFG_LLVM_ROOT
416415
export CFG_ENABLE_MINGW_CROSS

branches/snap-stage3/configure

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -806,7 +806,6 @@ do
806806
make_dir $h/test/doc-guide-container
807807
make_dir $h/test/doc-guide-tasks
808808
make_dir $h/test/doc-guide-conditions
809-
make_dir $h/test/doc-complement-cheatsheet
810809
make_dir $h/test/doc-rust
811810
done
812811

branches/snap-stage3/doc/complement-cheatsheet.md

Lines changed: 38 additions & 49 deletions
Original file line numberDiff line numberDiff line change
@@ -6,116 +6,113 @@
66

77
Use [`ToStr`](http://static.rust-lang.org/doc/master/std/to_str/trait.ToStr.html).
88

9-
~~~
9+
```rust
1010
let x: int = 42;
1111
let y: ~str = x.to_str();
12-
~~~
12+
```
1313

1414
**String to int**
1515

1616
Use [`FromStr`](http://static.rust-lang.org/doc/master/std/from_str/trait.FromStr.html), and its helper function, [`from_str`](http://static.rust-lang.org/doc/master/std/from_str/fn.from_str.html).
1717

18-
~~~
18+
```rust
1919
let x: Option<int> = from_str("42");
2020
let y: int = x.unwrap();
21-
~~~
21+
```
2222

2323
**Int to string, in non-base-10**
2424

2525
Use [`ToStrRadix`](http://static.rust-lang.org/doc/master/std/num/trait.ToStrRadix.html).
2626

27-
~~~
27+
```rust
2828
use std::num::ToStrRadix;
2929

3030
let x: int = 42;
3131
let y: ~str = x.to_str_radix(16);
32-
~~~
32+
```
3333

3434
**String to int, in non-base-10**
3535

3636
Use [`FromStrRadix`](http://static.rust-lang.org/doc/master/std/num/trait.FromStrRadix.html), and its helper function, [`from_str_radix`](http://static.rust-lang.org/doc/master/std/num/fn.from_str_radix.html).
3737

38-
~~~
38+
```rust
3939
use std::num::from_str_radix;
4040

41-
let x: Option<i64> = from_str_radix("deadbeef", 16);
42-
let y: i64 = x.unwrap();
43-
~~~
41+
let x: Option<int> = from_str_radix("deadbeef", 16);
42+
let y: int = x.unwrap();
43+
```
4444

4545
# File operations
4646

4747
## How do I read from a file?
4848

4949
Use [`File::open`](http://static.rust-lang.org/doc/master/std/io/fs/struct.File.html#method.open) to create a [`File`](http://static.rust-lang.org/doc/master/std/io/fs/struct.File.html) struct, which implements the [`Reader`](http://static.rust-lang.org/doc/master/std/io/trait.Reader.html) trait.
5050

51-
~~~ {.xfail-test}
51+
```rust
5252
use std::path::Path;
5353
use std::io::fs::File;
5454

5555
let path : Path = Path::new("Doc-FAQ-Cheatsheet.md");
5656
let on_error = || fail!("open of {:?} failed", path);
5757
let reader : File = File::open(&path).unwrap_or_else(on_error);
58-
~~~
58+
```
5959

6060
## How do I iterate over the lines in a file?
6161

6262
Use the [`lines`](http://static.rust-lang.org/doc/master/std/io/trait.Buffer.html#method.lines) method on a [`BufferedReader`](http://static.rust-lang.org/doc/master/std/io/buffered/struct.BufferedReader.html).
6363

64-
~~~
64+
```rust
6565
use std::io::buffered::BufferedReader;
66-
# use std::io::mem::MemReader;
67-
68-
# let reader = MemReader::new(~[]);
6966

7067
let mut reader = BufferedReader::new(reader);
7168
for line in reader.lines() {
7269
print!("line: {}", line);
7370
}
74-
~~~
71+
```
7572

7673
# String operations
7774

7875
## How do I search for a substring?
7976

8077
Use the [`find_str`](http://static.rust-lang.org/doc/master/std/str/trait.StrSlice.html#tymethod.find_str) method.
8178

82-
~~~
79+
```rust
8380
let str = "Hello, this is some random string";
8481
let index: Option<uint> = str.find_str("rand");
85-
~~~
82+
```
8683

8784
# Containers
8885

8986
## How do I get the length of a vector?
9087

9188
The [`Container`](http://static.rust-lang.org/doc/master/std/container/trait.Container.html) trait provides the `len` method.
9289

93-
~~~
90+
```rust
9491
let u: ~[u32] = ~[0, 1, 2];
9592
let v: &[u32] = &[0, 1, 2, 3];
9693
let w: [u32, .. 5] = [0, 1, 2, 3, 4];
9794

9895
println!("u: {}, v: {}, w: {}", u.len(), v.len(), w.len()); // 3, 4, 5
99-
~~~
96+
```
10097

10198
## How do I iterate over a vector?
10299

103100
Use the [`iter`](http://static.rust-lang.org/doc/master/std/vec/trait.ImmutableVector.html#tymethod.iter) method.
104101

105-
~~~
102+
```rust
106103
let values: ~[int] = ~[1, 2, 3, 4, 5];
107104
for value in values.iter() { // value: &int
108105
println!("{}", *value);
109106
}
110-
~~~
107+
```
111108

112109
(See also [`mut_iter`](http://static.rust-lang.org/doc/master/std/vec/trait.MutableVector.html#tymethod.mut_iter) which yields `&mut int` and [`move_iter`](http://static.rust-lang.org/doc/master/std/vec/trait.OwnedVector.html#tymethod.move_iter) which yields `int` while consuming the `values` vector.)
113110

114111
# Type system
115112

116113
## How do I store a function in a struct?
117114

118-
~~~
115+
```rust
119116
struct Foo {
120117
myfunc: fn(int, uint) -> i32
121118
}
@@ -134,27 +131,24 @@ fn main() {
134131
println!("{}", (f.myfunc)(1, 2));
135132
println!("{}", (g.myfunc)(3, 4));
136133
}
137-
~~~
134+
```
138135

139136
Note that the parenthesis surrounding `f.myfunc` are necessary: they are how Rust disambiguates field lookup and method call. The `'a` on `FooClosure` is the lifetime of the closure's environment pointer.
140137

141138
## How do I express phantom types?
142139

143140
[Phantom types](http://www.haskell.org/haskellwiki/Phantom_type) are those that cannot be constructed at compile time. To express these in Rust, zero-variant `enum`s can be used:
144141

145-
~~~
142+
```rust
146143
enum Open {}
147144
enum Closed {}
148-
~~~
145+
```
149146

150147
Phantom types are useful for enforcing state at compile time. For example:
151148

152-
~~~
149+
```rust
153150
struct Door<State>(~str);
154151

155-
struct Open;
156-
struct Closed;
157-
158152
fn close(Door(name): Door<Open>) -> Door<Closed> {
159153
Door::<Closed>(name)
160154
}
@@ -163,45 +157,40 @@ fn open(Door(name): Door<Closed>) -> Door<Open> {
163157
Door::<Open>(name)
164158
}
165159

166-
let _ = close(Door::<Open>(~"front"));
167-
~~~
168-
169-
Attempting to close a closed door is prevented statically:
170-
171-
~~~ {.xfail-test}
160+
let _ = close(Door::<Open>(~"front")); // ok
172161
let _ = close(Door::<Closed>(~"front")); // error: mismatched types: expected `main::Door<main::Open>` but found `main::Door<main::Closed>`
173-
~~~
162+
```
174163

175164
# FFI (Foreign Function Interface)
176165

177166
## C function signature conversions
178167

179-
Description C signature Equivalent Rust signature
180-
---------------------- ---------------------------------------------- ------------------------------------------
181-
no parameters `void foo(void);` `fn foo();`
182-
return value `int foo(void);` `fn foo() -> c_int;`
183-
function parameters `void foo(int x, int y);` `fn foo(x: int, y: int);`
184-
in-out pointers `void foo(const int* in_ptr, int* out_ptr);` `fn foo(in_ptr: *c_int, out_ptr: *mut c_int);`
168+
Description | C signature | Equivalent Rust signature
169+
----------------------|----------------------------------------------|------------------------------------------
170+
no parameters | `void foo(void);` | `fn foo();`
171+
return value | `int foo(void);` | `fn foo() -> c_int;`
172+
function parameters | `void foo(int x, int y);` | `fn foo(x: int, y: int);`
173+
in-out pointers | `void foo(const int* in_ptr, int* out_ptr);` | `fn foo(in_ptr: *c_int, out_ptr: *mut c_int);`
185174

186175
Note: The Rust signatures should be wrapped in an `extern "ABI" { ... }` block.
187176

188177
### Representing opaque handles
189178

190179
You might see things like this in C APIs:
191180

192-
~~~ {.notrust}
181+
```c
193182
typedef struct Window Window;
194183
Window* createWindow(int width, int height);
195-
~~~
184+
```
196185
197186
You can use a zero-element `enum` ([phantom type](#how-do-i-express-phantom-types)) to represent the opaque object handle. The FFI would look like this:
198187
199-
~~~ {.xfail-test}
188+
```rust
200189
enum Window {}
201190
extern "C" {
202191
fn createWindow(width: c_int, height: c_int) -> *Window;
203192
}
204-
~~~
193+
```
205194

206195
Using a phantom type ensures that the handles cannot be (safely) constructed in client code.
207196

@@ -211,4 +200,4 @@ For small examples, have full type annotations, as much as is reasonable, to kee
211200

212201
Similar documents for other programming languages:
213202

214-
* [http://pleac.sourceforge.net/](http://pleac.sourceforge.net)
203+
* [http://pleac.sourceforge.net/](http://pleac.sourceforge.net)

branches/snap-stage3/doc/complement-lang-faq.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -218,13 +218,13 @@ They start small (ideally in the hundreds of bytes) and expand dynamically by ca
218218
* Managed boxes may not be shared between tasks
219219
* Owned boxes may be transferred (moved) between tasks
220220

221-
## What is the difference between a reference (`&`) and managed and owned boxes?
221+
## What is the difference between a borrowed pointer (`&`) and managed and owned boxes?
222222

223-
* References point to the interior of a stack _or_ heap allocation
224-
* References can only be formed when it will provably be outlived by the referent
225-
* References to managed box pointers keep the managed boxes alive
226-
* References to owned boxes prevent their ownership from being transferred
227-
* References employ region-based alias analysis to ensure correctness
223+
* Borrowed pointers point to the interior of a stack _or_ heap allocation
224+
* Borrowed pointers can only be formed when it will provably be outlived by the referent
225+
* Borrowed pointers to managed box pointers keep the managed boxes alive
226+
* Borrowed pointers to owned boxes prevent their ownership from being transferred
227+
* Borrowed pointers employ region-based alias analysis to ensure correctness
228228

229229
## Why aren't function signatures inferred? Why only local slots?
230230

branches/snap-stage3/doc/guide-conditions.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
% The Rust Condition and Error-handling Guide
1+
% Rust Condition and Error-handling Guide
22

33
# Introduction
44

branches/snap-stage3/doc/guide-container.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
% The Rust Containers and Iterators Guide
1+
% Containers and Iterators Guide
22

33
# Containers
44

branches/snap-stage3/doc/guide-ffi.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
% The Rust Foreign Function Interface Guide
1+
% Rust Foreign Function Interface Guide
22

33
# Introduction
44

@@ -417,7 +417,7 @@ However, there are currently no guarantees about the layout of an `enum`.
417417

418418
Rust's owned and managed boxes use non-nullable pointers as handles which point to the contained
419419
object. However, they should not be manually created because they are managed by internal
420-
allocators. References can safely be assumed to be non-nullable pointers directly to the
420+
allocators. Borrowed pointers can safely be assumed to be non-nullable pointers directly to the
421421
type. However, breaking the borrow checking or mutability rules is not guaranteed to be safe, so
422422
prefer using raw pointers (`*`) if that's needed because the compiler can't make as many assumptions
423423
about them.

0 commit comments

Comments
 (0)