mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

auto merge of #11996 : lecram/rust/master, r=pcwalton

Browse Source 
This Pull Request aims to add backticks to all instances of code inside comments in snippets present in tutorial.md. It also includes backticks for filenames in the same conditions. See #11796 for motivation.
This commit is contained in:
bors 2014-02-02 08:41:27 -08:00
commit 2ff16b1849
1 changed files with 35 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
doc/tutorial.md
View File

@ -326,10 +326,10 @@ Rust will assume that an unsuffixed integer literal has type
`int`.
~~~~
let a = 1; // a is an int
let b = 10i; // b is an int, due to the 'i' suffix
let c = 100u; // c is a uint
let d = 1000i32; // d is an i32
let a = 1; // `a` is an `int`
let b = 10i; // `b` is an `int`, due to the `i` suffix
let c = 100u; // `c` is a `uint`
let d = 1000i32; // `d` is an `i32`
~~~~
There are two floating-point types: `f32`, and `f64`.
@ -400,10 +400,10 @@ error when the types of the directives don't match the types of the arguments.
~~~~
# let mystery_object = ();
// {} will print the "default format" of a type
// `{}` will print the "default format" of a type
println!("{} is {}", "the answer", 43);
// {:?} will conveniently print any type
// `{:?}` will conveniently print any type
println!("what is this thing: {:?}", mystery_object);
~~~~
@ -612,7 +612,7 @@ struct without inherited mutability would result in a type error.
let mut mypoint = Point { x: 1.0, y: 1.0 };
let origin = Point { x: 0.0, y: 0.0 };
mypoint.y += 1.0; // mypoint is mutable, and its fields as well
mypoint.y += 1.0; // `mypoint` is mutable, and its fields as well
origin.y += 1.0; // ERROR: assigning to immutable field
~~~~
@ -1085,8 +1085,8 @@ Avoiding a move can be done with the library-defined `clone` method:
~~~~
let x = ~5;
let y = x.clone(); // y is a newly allocated box
let z = x; // no new memory allocated, x can no longer be used
let y = x.clone(); // `y` is a newly allocated box
let z = x; // no new memory allocated, `x` can no longer be used
~~~~
The `clone` method is provided by the `Clone` trait, and can be derived for
@ -1340,7 +1340,7 @@ fn foo() -> (u64, u64, u64, u64, u64, u64) {
(5, 5, 5, 5, 5, 5)
}
let x = ~foo(); // allocates a ~ box, and writes the integers directly to it
let x = ~foo(); // allocates a `~` box, and writes the integers directly to it
~~~~
Beyond the properties granted by the size, an owned box behaves as a regular
@ -1353,7 +1353,7 @@ y += 2;
let x = ~5; // immutable
let mut y = ~5; // mutable
*y += 2; // the * operator is needed to access the contained value
*y += 2; // the `*` operator is needed to access the contained value
~~~~
# References
@ -1451,9 +1451,9 @@ of a non-`Freeze` type is [`RefCell<T>`][refcell].
~~~~
let mut x = 5;
{
let y = &x; // x is now frozen, it cannot be modified
let y = &x; // `x` is now frozen, it cannot be modified
}
// x is now unfrozen again
// `x` is now unfrozen again
# x = 3;
~~~~
@ -1559,7 +1559,7 @@ let mut numbers = ~[1, 2, 3];
numbers.push(4);
numbers.push(5);
// The type of a unique vector is written as ~[int]
// The type of a unique vector is written as `~[int]`
let more_numbers: ~[int] = numbers;
// The original `numbers` value can no longer be used, due to move semantics.
@ -1576,7 +1576,7 @@ the elements.
// A slice
let xs = &[1, 2, 3];
// Slices have their type written as &[int]
// Slices have their type written as `&[int]`
let ys: &[int] = xs;
// Other vector types coerce to slices
@ -1586,7 +1586,7 @@ let zs: &[int] = three;
// An unadorned string literal is an immutable string slice
let string = "foobar";
// A string slice type is written as &str
// A string slice type is written as `&str`
let view: &str = string.slice(0, 3);
~~~
@ -1600,7 +1600,7 @@ let mut xs = [1, 2, 3];
let view = xs.mut_slice(0, 2);
view[0] = 5;
// The type of a mutable slice is written as &mut [T]
// The type of a mutable slice is written as `&mut [T]`
let ys: &mut [int] = &mut [1, 2, 3];
~~~
@ -2546,7 +2546,7 @@ that binary is collectively called a 'crate'.
For example, for a simple hello world program your crate only consists of this code:
~~~~
// main.rs
// `main.rs`
fn main() {
println!("Hello world!");
}
@ -2675,8 +2675,8 @@ fn main() {
f.farmer.rest();
// This wouldn't compile because both are private:
// f.feed_chickens();
// let chicken_counter = f.chickens.len();
// `f.feed_chickens();`
// `let chicken_counter = f.chickens.len();`
}
# fn make_me_a_farm() -> farm::Farm { farm::make_me_a_farm() }
# fn make_me_a_chicken() -> farm::Chicken { 0 }
@ -2708,8 +2708,8 @@ If it finds both, that's a compile error.
So, if we want to move the content of `mod farm` into it's own file, it would look like this:
~~~~ {.ignore}
// main.rs - contains body of the crate root
mod farm; // Compiler will look for 'farm.rs' and 'farm/mod.rs'
// `main.rs` - contains body of the crate root
mod farm; // Compiler will look for `farm.rs` and `farm/mod.rs`
fn main() {
println!("Hello farm!");
@ -2718,7 +2718,7 @@ fn main() {
~~~~
~~~~
// farm.rs - contains body of module 'farm' in the crate root
// `farm.rs` - contains body of module 'farm' in the crate root
pub fn chicken() { println!("cluck cluck"); }
pub fn cow() { println!("mooo"); }
@ -2743,7 +2743,7 @@ is contained in, if any.
For example, given a file with this module body:
~~~ {.ignore}
// src/main.rs
// `src/main.rs`
mod plants;
mod animals {
mod fish;
@ -2771,13 +2771,13 @@ depending on how and where you've moved a module body to its own file.
For example, if we move the `animals` module above into its own file...
~~~ {.ignore}
// src/main.rs
// `src/main.rs`
mod plants;
mod animals;
~~~
~~~ {.ignore}
// src/animals.rs or src/animals/mod.rs
// `src/animals.rs` or `src/animals/mod.rs`
mod fish;
mod mammals {
mod humans;
@ -2874,7 +2874,7 @@ use farm::cow;
fn cow() { println!("Mooo!") }
fn main() {
cow() // resolves to the locally defined cow() function
cow() // resolves to the locally defined `cow()` function
}
~~~
@ -2924,21 +2924,21 @@ fn main() {
And here an example with multiple files:
~~~{.ignore}
// a.rs - crate root
// `a.rs` - crate root
use b::foo;
mod b;
fn main() { foo(); }
~~~
~~~{.ignore}
// b.rs
// `b.rs`
use b::c::bar;
pub mod c;
pub fn foo() { bar(); }
~~~
~~~
// c.rs
// `c.rs`
pub fn bar() { println!("Baz!"); }
# fn main() {}
~~~
@ -3101,7 +3101,7 @@ without conflict.
Therefore, if you plan to compile your crate as a library, you should annotate it with that information:
~~~~
// lib.rs
// `lib.rs`
# #[crate_type = "lib"];
// Package ID
@ -3125,7 +3125,7 @@ Other crate settings and metadata include things like enabling/disabling certain
or setting the crate type (library or executable) explicitly:
~~~~
// lib.rs
// `lib.rs`
// ...
// This crate is a library ("bin" is the default)
@ -3144,7 +3144,7 @@ Now for something that you can actually compile yourself.
We define two crates, and use one of them as a library in the other.
~~~~
// world.rs
// `world.rs`
#[crate_id = "world#0.42"];
# extern mod extra;
pub fn explore() -> &'static str { "world" }
@ -3152,7 +3152,7 @@ pub fn explore() -> &'static str { "world" }
~~~~
~~~~ {.ignore}
// main.rs
// `main.rs`
extern mod world;
fn main() { println!("hello {}", world::explore()); }
~~~~
@ -3203,7 +3203,7 @@ For example, it re-exports `range` which is defined in `std::iter::range`:
use iter_range = std::iter::range;
fn main() {
// range is imported by default
// `range` is imported by default
for _ in range(0, 10) {}
// Doesn't hinder you from importing it under a different name yourself