Rollup merge of #25580 - killercup:trpl/unify-code-blocks, r=steveklabnik
This adds strictly more information to the source files and reduces the need for customized tooling to render the book. (While this should not change the output of _rustbook_, it is very useful when rendering the sources with external tools like Pandoc.) This only adds the language marker to "first level" code blocks (and not to code blocks in comments inside of code examples). r? @steveklabnik
This commit is contained in:
commit
b613ef552d
@ -3,7 +3,7 @@
|
||||
Rust supports benchmark tests, which can test the performance of your
|
||||
code. Let's make our `src/lib.rs` look like this (comments elided):
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
#![feature(test)]
|
||||
|
||||
extern crate test;
|
||||
@ -77,7 +77,7 @@ the benchmark is no longer benchmarking what one expects. For example, the
|
||||
compiler might recognize that some calculation has no external effects and
|
||||
remove it entirely.
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
#![feature(test)]
|
||||
|
||||
extern crate test;
|
||||
|
@ -51,7 +51,7 @@ kind of borrowed value. This is especially true of references and slices: you
|
||||
can have both an `&T` or a `&mut T`. If we wanted to accept both of these types,
|
||||
`Borrow` is up for it:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::borrow::Borrow;
|
||||
use std::fmt::Display;
|
||||
|
||||
|
@ -5,7 +5,7 @@ Also it is not possible in stable Rust to destructure a `Box` in a match
|
||||
pattern. The unstable `box` keyword can be used to both create and destructure
|
||||
a `Box`. An example usage would be:
|
||||
|
||||
```
|
||||
```rust
|
||||
#![feature(box_syntax, box_patterns)]
|
||||
|
||||
fn main() {
|
||||
@ -34,7 +34,7 @@ because the syntax may still change in the future.
|
||||
In many languages with pointers, you'd return a pointer from a function
|
||||
so as to avoid copying a large data structure. For example:
|
||||
|
||||
```{rust}
|
||||
```rust
|
||||
struct BigStruct {
|
||||
one: i32,
|
||||
two: i32,
|
||||
|
@ -59,7 +59,7 @@ place!
|
||||
Rust's standard library provides a library for threads, which allow you to
|
||||
run Rust code in parallel. Here's a basic example of using `std::thread`:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::thread;
|
||||
|
||||
fn main() {
|
||||
@ -73,7 +73,7 @@ The `thread::spawn()` method accepts a closure, which is executed in a
|
||||
new thread. It returns a handle to the thread, that can be used to
|
||||
wait for the child thread to finish and extract its result:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::thread;
|
||||
|
||||
fn main() {
|
||||
@ -189,7 +189,7 @@ guard across thread boundaries, which gives us our error.
|
||||
|
||||
We can use `Arc<T>` to fix this. Here's the working version:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::sync::{Arc, Mutex};
|
||||
use std::thread;
|
||||
|
||||
@ -248,7 +248,7 @@ threads with each other. Let's talk about one of them: channels.
|
||||
Here's a version of our code that uses channels for synchronization, rather
|
||||
than waiting for a specific time:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::sync::{Arc, Mutex};
|
||||
use std::thread;
|
||||
use std::sync::mpsc;
|
||||
@ -281,7 +281,7 @@ a simple `()` down the channel, and then wait for ten of them to come back.
|
||||
While this channel is just sending a generic signal, we can send any data that
|
||||
is `Send` over the channel!
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::thread;
|
||||
use std::sync::mpsc;
|
||||
|
||||
@ -311,7 +311,7 @@ the answer, and then it `send()`s us the answer over the channel.
|
||||
A `panic!` will crash the currently executing thread. You can use Rust's
|
||||
threads as a simple isolation mechanism:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::thread;
|
||||
|
||||
let result = thread::spawn(move || {
|
||||
|
@ -75,7 +75,7 @@ above.
|
||||
To define each of our modules, we use the `mod` keyword. Let’s make our
|
||||
`src/lib.rs` look like this:
|
||||
|
||||
```
|
||||
```rust
|
||||
mod english {
|
||||
mod greetings {
|
||||
}
|
||||
@ -126,7 +126,7 @@ ways.
|
||||
|
||||
Instead of declaring a module like this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
mod english {
|
||||
// contents of our module go here
|
||||
}
|
||||
@ -134,7 +134,7 @@ mod english {
|
||||
|
||||
We can instead declare our module like this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
mod english;
|
||||
```
|
||||
|
||||
@ -173,7 +173,7 @@ $ tree .
|
||||
|
||||
`src/lib.rs` is our crate root, and looks like this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
mod english;
|
||||
mod japanese;
|
||||
```
|
||||
@ -184,7 +184,7 @@ on our preference. In this case, because our modules have sub-modules, we’ve
|
||||
chosen the second. Both `src/english/mod.rs` and `src/japanese/mod.rs` look
|
||||
like this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
mod greetings;
|
||||
mod farewells;
|
||||
```
|
||||
@ -297,7 +297,7 @@ public, and so private is the default. To make things public, you use the `pub`
|
||||
keyword. Let’s focus on the `english` module first, so let’s reduce our `src/main.rs`
|
||||
to just this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
extern crate phrases;
|
||||
|
||||
fn main() {
|
||||
@ -308,21 +308,21 @@ fn main() {
|
||||
|
||||
In our `src/lib.rs`, let’s add `pub` to the `english` module declaration:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub mod english;
|
||||
mod japanese;
|
||||
```
|
||||
|
||||
And in our `src/english/mod.rs`, let’s make both `pub`:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub mod greetings;
|
||||
pub mod farewells;
|
||||
```
|
||||
|
||||
In our `src/english/greetings.rs`, let’s add `pub` to our `fn` declaration:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub fn hello() -> String {
|
||||
"Hello!".to_string()
|
||||
}
|
||||
@ -330,7 +330,7 @@ pub fn hello() -> String {
|
||||
|
||||
And also in `src/english/farewells.rs`:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub fn goodbye() -> String {
|
||||
"Goodbye.".to_string()
|
||||
}
|
||||
@ -365,7 +365,7 @@ refer to them with shorter names. Let’s talk about `use`.
|
||||
Rust has a `use` keyword, which allows us to import names into our local scope.
|
||||
Let’s change our `src/main.rs` to look like this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
extern crate phrases;
|
||||
|
||||
use phrases::english::greetings;
|
||||
@ -382,7 +382,7 @@ the functions by a much shorter name. By convention, when importing functions, i
|
||||
considered best practice to import the module, rather than the function directly. In
|
||||
other words, you _can_ do this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
extern crate phrases;
|
||||
|
||||
use phrases::english::greetings::hello;
|
||||
@ -400,7 +400,7 @@ becomes a problem. If we have conflicting names, Rust will give a compilation
|
||||
error. For example, if we made the `japanese` functions public, and tried to do
|
||||
this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
extern crate phrases;
|
||||
|
||||
use phrases::english::greetings::hello;
|
||||
@ -426,14 +426,14 @@ Could not compile `phrases`.
|
||||
If we’re importing multiple names from the same module, we don’t have to type it out
|
||||
twice. Instead of this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
use phrases::english::greetings;
|
||||
use phrases::english::farewells;
|
||||
```
|
||||
|
||||
We can use this shortcut:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
use phrases::english::{greetings, farewells};
|
||||
```
|
||||
|
||||
@ -445,7 +445,7 @@ interface that may not directly map to your internal code organization.
|
||||
|
||||
Let’s look at an example. Modify your `src/main.rs` to read like this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
extern crate phrases;
|
||||
|
||||
use phrases::english::{greetings,farewells};
|
||||
@ -462,14 +462,14 @@ fn main() {
|
||||
|
||||
Then, modify your `src/lib.rs` to make the `japanese` mod public:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub mod english;
|
||||
pub mod japanese;
|
||||
```
|
||||
|
||||
Next, make the two functions public, first in `src/japanese/greetings.rs`:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub fn hello() -> String {
|
||||
"こんにちは".to_string()
|
||||
}
|
||||
@ -477,7 +477,7 @@ pub fn hello() -> String {
|
||||
|
||||
And then in `src/japanese/farewells.rs`:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub fn goodbye() -> String {
|
||||
"さようなら".to_string()
|
||||
}
|
||||
@ -485,7 +485,7 @@ pub fn goodbye() -> String {
|
||||
|
||||
Finally, modify your `src/japanese/mod.rs` to read like this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub use self::greetings::hello;
|
||||
pub use self::farewells::goodbye;
|
||||
|
||||
|
@ -42,7 +42,7 @@ Documentation comments are written in Markdown.
|
||||
Rust keeps track of these comments, and uses them when generating
|
||||
documentation. This is important when documenting things like enums:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// The `Option` type. See [the module level documentation](../) for more.
|
||||
enum Option<T> {
|
||||
/// No value
|
||||
@ -80,7 +80,7 @@ thing after that last comment.
|
||||
|
||||
Anyway, let's cover each part of this comment in detail:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// Constructs a new `Rc<T>`.
|
||||
# fn foo() {}
|
||||
```
|
||||
@ -88,7 +88,7 @@ Anyway, let's cover each part of this comment in detail:
|
||||
The first line of a documentation comment should be a short summary of its
|
||||
functionality. One sentence. Just the basics. High level.
|
||||
|
||||
```
|
||||
```rust
|
||||
///
|
||||
/// Other details about constructing `Rc<T>`s, maybe describing complicated
|
||||
/// semantics, maybe additional options, all kinds of stuff.
|
||||
@ -101,7 +101,7 @@ we could have added more explanation in a new paragraph.
|
||||
|
||||
#### Special sections
|
||||
|
||||
```
|
||||
```rust
|
||||
/// # Examples
|
||||
# fn foo() {}
|
||||
```
|
||||
@ -110,7 +110,7 @@ Next, are special sections. These are indicated with a header, `#`. There
|
||||
are three kinds of headers that are commonly used. They aren't special syntax,
|
||||
just convention, for now.
|
||||
|
||||
```
|
||||
```rust
|
||||
/// # Panics
|
||||
# fn foo() {}
|
||||
```
|
||||
@ -120,7 +120,7 @@ usually indicated by panics, which kill the whole current thread at the very
|
||||
least. If your function has a non-trivial contract like this, that is
|
||||
detected/enforced by panics, documenting it is very important.
|
||||
|
||||
```
|
||||
```rust
|
||||
/// # Failures
|
||||
# fn foo() {}
|
||||
```
|
||||
@ -130,7 +130,7 @@ conditions under which it returns `Err(E)` is a nice thing to do. This is
|
||||
slightly less important than `Panics`, because failure is encoded into the type
|
||||
system, but it's still a good thing to do.
|
||||
|
||||
```
|
||||
```rust
|
||||
/// # Safety
|
||||
# fn foo() {}
|
||||
```
|
||||
@ -138,7 +138,7 @@ system, but it's still a good thing to do.
|
||||
If your function is `unsafe`, you should explain which invariants the caller is
|
||||
responsible for upholding.
|
||||
|
||||
```
|
||||
```rust
|
||||
/// # Examples
|
||||
///
|
||||
/// ```
|
||||
@ -154,7 +154,7 @@ method, and your users will love you for it. These examples go inside of
|
||||
code block annotations, which we'll talk about in a moment, and can have
|
||||
more than one section:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// # Examples
|
||||
///
|
||||
/// Simple `&str` patterns:
|
||||
@ -179,7 +179,7 @@ Let's discuss the details of these code blocks.
|
||||
|
||||
To write some Rust code in a comment, use the triple graves:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// ```
|
||||
/// println!("Hello, world");
|
||||
/// ```
|
||||
@ -188,7 +188,7 @@ To write some Rust code in a comment, use the triple graves:
|
||||
|
||||
If you want something that's not Rust code, you can add an annotation:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// ```c
|
||||
/// printf("Hello, world\n");
|
||||
/// ```
|
||||
@ -208,7 +208,7 @@ generate the documentation.
|
||||
|
||||
Let's discuss our sample example documentation:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// ```
|
||||
/// println!("Hello, world");
|
||||
/// ```
|
||||
@ -219,7 +219,7 @@ You'll notice that you don't need a `fn main()` or anything here. `rustdoc` will
|
||||
automatically add a main() wrapper around your code, and in the right place.
|
||||
For example:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// ```
|
||||
/// use std::rc::Rc;
|
||||
///
|
||||
@ -230,7 +230,7 @@ For example:
|
||||
|
||||
This will end up testing:
|
||||
|
||||
```
|
||||
```rust
|
||||
fn main() {
|
||||
use std::rc::Rc;
|
||||
let five = Rc::new(5);
|
||||
@ -259,7 +259,7 @@ with `///` we've been talking about? The raw text:
|
||||
|
||||
looks different than the output:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// Some documentation.
|
||||
# fn foo() {}
|
||||
```
|
||||
@ -274,7 +274,7 @@ it makes the example more clear. You can use this technique to explain
|
||||
longer examples in detail, while still preserving the testability of your
|
||||
documentation. For example, this code:
|
||||
|
||||
```
|
||||
```rust
|
||||
let x = 5;
|
||||
let y = 6;
|
||||
println!("{}", x + y);
|
||||
@ -284,7 +284,7 @@ Here's an explanation, rendered:
|
||||
|
||||
First, we set `x` to five:
|
||||
|
||||
```
|
||||
```rust
|
||||
let x = 5;
|
||||
# let y = 6;
|
||||
# println!("{}", x + y);
|
||||
@ -292,7 +292,7 @@ let x = 5;
|
||||
|
||||
Next, we set `y` to six:
|
||||
|
||||
```
|
||||
```rust
|
||||
# let x = 5;
|
||||
let y = 6;
|
||||
# println!("{}", x + y);
|
||||
@ -300,7 +300,7 @@ let y = 6;
|
||||
|
||||
Finally, we print the sum of `x` and `y`:
|
||||
|
||||
```
|
||||
```rust
|
||||
# let x = 5;
|
||||
# let y = 6;
|
||||
println!("{}", x + y);
|
||||
@ -340,7 +340,7 @@ explanation.
|
||||
|
||||
Here’s an example of documenting a macro:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// Panic with a given message unless an expression evaluates to true.
|
||||
///
|
||||
/// # Examples
|
||||
@ -388,7 +388,7 @@ but with a binary, there’s nothing to link to.
|
||||
There are a few more annotations that are useful to help `rustdoc` do the right
|
||||
thing when testing your code:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// ```ignore
|
||||
/// fn foo() {
|
||||
/// ```
|
||||
@ -400,7 +400,7 @@ what you want, as it's the most generic. Instead, consider annotating it
|
||||
with `text` if it's not code, or using `#`s to get a working example that
|
||||
only shows the part you care about.
|
||||
|
||||
```
|
||||
```rust
|
||||
/// ```should_panic
|
||||
/// assert!(false);
|
||||
/// ```
|
||||
@ -410,7 +410,7 @@ only shows the part you care about.
|
||||
`should_panic` tells `rustdoc` that the code should compile correctly, but
|
||||
not actually pass as a test.
|
||||
|
||||
```
|
||||
```rust
|
||||
/// ```no_run
|
||||
/// loop {
|
||||
/// println!("Hello, world");
|
||||
@ -427,7 +427,7 @@ which you would want to make sure compile, but might run in an infinite loop!
|
||||
|
||||
Rust has another kind of doc comment, `//!`. This comment doesn't document the next item, but the enclosing item. In other words:
|
||||
|
||||
```
|
||||
```rust
|
||||
mod foo {
|
||||
//! This is documentation for the `foo` module.
|
||||
//!
|
||||
@ -440,7 +440,7 @@ mod foo {
|
||||
This is where you'll see `//!` used most often: for module documentation. If
|
||||
you have a module in `foo.rs`, you'll often open its code and see this:
|
||||
|
||||
```
|
||||
```rust
|
||||
//! A module for using `foo`s.
|
||||
//!
|
||||
//! The `foo` module contains a lot of useful functionality blah blah blah
|
||||
@ -461,7 +461,7 @@ are written in Markdown, they're often `.md` files.
|
||||
When you write documentation in Markdown files, you don't need to prefix
|
||||
the documentation with comments. For example:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// # Examples
|
||||
///
|
||||
/// ```
|
||||
@ -499,7 +499,7 @@ This `%` line needs to be the very first line of the file.
|
||||
|
||||
At a deeper level, documentation comments are sugar for documentation attributes:
|
||||
|
||||
```
|
||||
```rust
|
||||
/// this
|
||||
# fn foo() {}
|
||||
|
||||
@ -509,7 +509,7 @@ At a deeper level, documentation comments are sugar for documentation attributes
|
||||
|
||||
are the same, as are these:
|
||||
|
||||
```
|
||||
```rust
|
||||
//! this
|
||||
|
||||
#![doc="/// this"]
|
||||
@ -546,7 +546,7 @@ pub use foo::bar;
|
||||
You can control a few aspects of the HTML that `rustdoc` generates through the
|
||||
`#![doc]` version of the attribute:
|
||||
|
||||
```
|
||||
```rust
|
||||
#![doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk-v2.png",
|
||||
html_favicon_url = "http://www.rust-lang.org/favicon.ico",
|
||||
html_root_url = "http://doc.rust-lang.org/")];
|
||||
|
@ -49,7 +49,7 @@ We use `assert!` to declare that something is true. If it's not true, something
|
||||
is very wrong. Wrong enough that we can't continue with things in the current
|
||||
state. Another example is using the `unreachable!()` macro:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
enum Event {
|
||||
NewRelease,
|
||||
}
|
||||
@ -188,7 +188,7 @@ The [`Debug`](../std/fmt/trait.Debug.html) trait is what lets us print the enum
|
||||
In the case of an error that is unexpected and not recoverable, the `panic!`
|
||||
macro will induce a panic. This will crash the current thread, and give an error:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
panic!("boom");
|
||||
```
|
||||
|
||||
@ -212,7 +212,7 @@ handle and possibly recover from error.
|
||||
If we don't want to handle this error, and would rather just abort the program,
|
||||
we can use the `unwrap()` method:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
io::stdin().read_line(&mut buffer).unwrap();
|
||||
```
|
||||
|
||||
@ -223,7 +223,7 @@ shorter. Sometimes, just crashing is appropriate.
|
||||
|
||||
There's another way of doing this that's a bit nicer than `unwrap()`:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
let mut buffer = String::new();
|
||||
let input = io::stdin().read_line(&mut buffer)
|
||||
.ok()
|
||||
|
@ -81,7 +81,7 @@ vectors as pointers to memory. Rust's vectors are guaranteed to be a contiguous
|
||||
length is number of elements currently contained, and the capacity is the total size in elements of
|
||||
the allocated memory. The length is less than or equal to the capacity.
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(libc)]
|
||||
# extern crate libc;
|
||||
# use libc::{c_int, size_t};
|
||||
@ -106,7 +106,7 @@ required capacity to hold the compressed output. The vector can then be passed t
|
||||
`snappy_compress` function as an output parameter. An output parameter is also passed to retrieve
|
||||
the true length after compression for setting the length.
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(libc)]
|
||||
# extern crate libc;
|
||||
# use libc::{size_t, c_int};
|
||||
@ -133,7 +133,7 @@ pub fn compress(src: &[u8]) -> Vec<u8> {
|
||||
Decompression is similar, because snappy stores the uncompressed size as part of the compression
|
||||
format and `snappy_uncompressed_length` will retrieve the exact buffer size required.
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(libc)]
|
||||
# extern crate libc;
|
||||
# use libc::{size_t, c_int};
|
||||
@ -375,7 +375,7 @@ the compiler that the unsafety does not leak out of the block.
|
||||
Unsafe functions, on the other hand, advertise it to the world. An unsafe function is written like
|
||||
this:
|
||||
|
||||
```
|
||||
```rust
|
||||
unsafe fn kaboom(ptr: *const i32) -> i32 { *ptr }
|
||||
```
|
||||
|
||||
@ -439,7 +439,7 @@ Most foreign code exposes a C ABI, and Rust uses the platform's C calling conven
|
||||
calling foreign functions. Some foreign functions, most notably the Windows API, use other calling
|
||||
conventions. Rust provides a way to tell the compiler which convention to use:
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(libc)]
|
||||
extern crate libc;
|
||||
|
||||
@ -516,7 +516,7 @@ function pointer using the C ABI.
|
||||
You may wish to compile Rust code in a way so that it can be called from C. This is
|
||||
fairly easy, but requires a few things:
|
||||
|
||||
```
|
||||
```rust
|
||||
#[no_mangle]
|
||||
pub extern fn hello_rust() -> *const u8 {
|
||||
"Hello, world!\0".as_ptr()
|
||||
|
@ -146,7 +146,7 @@ expression, although its value is not particularly useful. Unlike other
|
||||
languages where an assignment evaluates to the assigned value (e.g. `5` in the
|
||||
previous example), in Rust the value of an assignment is an empty tuple `()`:
|
||||
|
||||
```
|
||||
```rust
|
||||
let mut y = 5;
|
||||
|
||||
let x = (y = 6); // x has the value `()`, not `6`
|
||||
@ -204,7 +204,7 @@ time.
|
||||
Rust has some special syntax for ‘diverging functions’, which are functions that
|
||||
do not return:
|
||||
|
||||
```
|
||||
```rust
|
||||
fn diverges() -> ! {
|
||||
panic!("This function never returns!");
|
||||
}
|
||||
|
@ -110,7 +110,7 @@ Generic functions are most useful with ‘trait bounds’, which we’ll cover i
|
||||
|
||||
You can store a generic type in a `struct` as well:
|
||||
|
||||
```
|
||||
```rust
|
||||
struct Point<T> {
|
||||
x: T,
|
||||
y: T,
|
||||
|
@ -151,7 +151,7 @@ take a name on the left hand side, it actually accepts a
|
||||
‘[pattern][patterns]’. We’ll use patterns more later. It’s easy enough
|
||||
to use for now:
|
||||
|
||||
```
|
||||
```rust
|
||||
let foo = 5; // immutable.
|
||||
let mut bar = 5; // mutable
|
||||
```
|
||||
|
@ -25,7 +25,7 @@ crate to allow) and of course requires an `unsafe` block.
|
||||
The `assembly template` is the only required parameter and must be a
|
||||
literal string (i.e. `""`)
|
||||
|
||||
```
|
||||
```rust
|
||||
#![feature(asm)]
|
||||
|
||||
#[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
|
||||
@ -51,7 +51,7 @@ fn main() {
|
||||
Output operands, input operands, clobbers and options are all optional
|
||||
but you must add the right number of `:` if you skip them:
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(asm)]
|
||||
# #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
|
||||
# fn main() { unsafe {
|
||||
@ -65,7 +65,7 @@ asm!("xor %eax, %eax"
|
||||
|
||||
Whitespace also doesn't matter:
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(asm)]
|
||||
# #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
|
||||
# fn main() { unsafe {
|
||||
@ -79,7 +79,7 @@ Input and output operands follow the same format: `:
|
||||
"constraints1"(expr1), "constraints2"(expr2), ..."`. Output operand
|
||||
expressions must be mutable lvalues, or not yet assigned:
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(asm)]
|
||||
# #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
|
||||
fn add(a: i32, b: i32) -> i32 {
|
||||
@ -106,7 +106,7 @@ you want, and you are required to put the specific size of the
|
||||
operand. This is useful for very low level programming, where
|
||||
which register you use is important:
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(asm)]
|
||||
# #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
|
||||
# unsafe fn read_byte_in(port: u16) -> u8 {
|
||||
@ -123,7 +123,7 @@ different values so we use the clobbers list to indicate to the
|
||||
compiler not to assume any values loaded into those registers will
|
||||
stay valid.
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(asm)]
|
||||
# #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
|
||||
# fn main() { unsafe {
|
||||
@ -155,7 +155,7 @@ Current valid options are:
|
||||
the compiler to insert its usual stack alignment code
|
||||
3. *intel* - use intel syntax instead of the default AT&T.
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(asm)]
|
||||
# #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
|
||||
# fn main() {
|
||||
|
@ -10,7 +10,7 @@ context, but wished to be able to `transmute` between types, and
|
||||
perform efficient pointer arithmetic, one would import those functions
|
||||
via a declaration like
|
||||
|
||||
```
|
||||
```rust
|
||||
# #![feature(intrinsics)]
|
||||
# fn main() {}
|
||||
|
||||
|
@ -116,7 +116,7 @@ A *consumer* operates on an iterator, returning some kind of value or values.
|
||||
The most common consumer is `collect()`. This code doesn't quite compile,
|
||||
but it shows the intention:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
let one_to_one_hundred = (1..101).collect();
|
||||
```
|
||||
|
||||
@ -253,7 +253,7 @@ we need to talk about with regards to iterators. Let's get to it!
|
||||
*Iterator adapters* take an iterator and modify it somehow, producing
|
||||
a new iterator. The simplest one is called `map`:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
(1..100).map(|x| x + 1);
|
||||
```
|
||||
|
||||
@ -272,7 +272,7 @@ warning: unused result which must be used: iterator adaptors are lazy and
|
||||
Laziness strikes again! That closure will never execute. This example
|
||||
doesn't print any numbers:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
(1..100).map(|x| println!("{}", x));
|
||||
```
|
||||
|
||||
|
@ -15,7 +15,7 @@ For example, `Box` pointers require two lang items, one for allocation
|
||||
and one for deallocation. A freestanding program that uses the `Box`
|
||||
sugar for dynamic allocations via `malloc` and `free`:
|
||||
|
||||
```
|
||||
```rust
|
||||
#![feature(lang_items, box_syntax, start, no_std, libc)]
|
||||
#![no_std]
|
||||
|
||||
|
@ -698,6 +698,7 @@ assert_eq!(5, 3 + 2);
|
||||
assert!(5 < 3);
|
||||
assert_eq!(5, 3);
|
||||
```
|
||||
|
||||
## try!
|
||||
|
||||
`try!` is used for error handling. It takes something that can return a
|
||||
|
@ -89,7 +89,7 @@ So, now we know how to call a method, such as `foo.bar()`. But what about our
|
||||
original example, `foo.bar().baz()`? This is called ‘method chaining’, and we
|
||||
can do it by returning `self`.
|
||||
|
||||
```
|
||||
```rust
|
||||
struct Circle {
|
||||
x: f64,
|
||||
y: f64,
|
||||
@ -117,7 +117,7 @@ fn main() {
|
||||
|
||||
Check the return type:
|
||||
|
||||
```
|
||||
```rust
|
||||
# struct Circle;
|
||||
# impl Circle {
|
||||
fn grow(&self) -> Circle {
|
||||
@ -167,7 +167,7 @@ and `y` attributes will be `0.0`, and the `radius` will be `1.0`. Rust doesn’t
|
||||
have method overloading, named arguments, or variable arguments. We employ
|
||||
the builder pattern instead. It looks like this:
|
||||
|
||||
```
|
||||
```rust
|
||||
struct Circle {
|
||||
x: f64,
|
||||
y: f64,
|
||||
|
@ -161,7 +161,7 @@ b.x = 10; // error: cannot assign to immutable field `b.x`
|
||||
|
||||
However, by using `Cell<T>`, you can emulate field-level mutability:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::cell::Cell;
|
||||
|
||||
struct Point {
|
||||
|
@ -20,7 +20,7 @@ default shim for the C `main` function with your own.
|
||||
The function marked `#[start]` is passed the command line parameters
|
||||
in the same format as C:
|
||||
|
||||
```
|
||||
```rust
|
||||
#![feature(lang_items, start, no_std, libc)]
|
||||
#![no_std]
|
||||
|
||||
|
@ -251,7 +251,7 @@ This pattern is very powerful, and we’ll see it repeated more later.
|
||||
You can disambiguate a single-element tuple from a value in parentheses with a
|
||||
comma:
|
||||
|
||||
```
|
||||
```rust
|
||||
(0,); // single-element tuple
|
||||
(0); // zero in parentheses
|
||||
```
|
||||
@ -283,7 +283,7 @@ documentation][tuple].
|
||||
|
||||
Functions also have a type! They look like this:
|
||||
|
||||
```
|
||||
```rust
|
||||
fn foo(x: i32) -> i32 { x }
|
||||
|
||||
let x: fn(i32) -> i32 = foo;
|
||||
|
@ -38,7 +38,7 @@ println!("{}", s);
|
||||
|
||||
`String`s will coerce into `&str` with an `&`:
|
||||
|
||||
```
|
||||
```rust
|
||||
fn takes_slice(slice: &str) {
|
||||
println!("Got: {}", slice);
|
||||
}
|
||||
|
@ -195,7 +195,7 @@ parameter can be added to the `should_panic` attribute. The test harness will
|
||||
make sure that the failure message contains the provided text. A safer version
|
||||
of the example above would be:
|
||||
|
||||
```
|
||||
```rust
|
||||
#[test]
|
||||
#[should_panic(expected = "assertion failed")]
|
||||
fn it_works() {
|
||||
@ -205,7 +205,7 @@ fn it_works() {
|
||||
|
||||
That's all there is to the basics! Let's write one 'real' test:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub fn add_two(a: i32) -> i32 {
|
||||
a + 2
|
||||
}
|
||||
@ -225,7 +225,7 @@ There is one way in which our existing example is not idiomatic: it's
|
||||
missing the `tests` module. The idiomatic way of writing our example
|
||||
looks like this:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
pub fn add_two(a: i32) -> i32 {
|
||||
a + 2
|
||||
}
|
||||
@ -253,7 +253,7 @@ we need to bring our test function into scope. This can be annoying if you have
|
||||
a large module, and so this is a common use of the `glob` feature. Let's change
|
||||
our `src/lib.rs` to make use of it:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
|
||||
pub fn add_two(a: i32) -> i32 {
|
||||
a + 2
|
||||
@ -302,7 +302,7 @@ the `tests` directory
|
||||
To write an integration test, let's make a `tests` directory, and
|
||||
put a `tests/lib.rs` file inside, with this as its contents:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
extern crate adder;
|
||||
|
||||
#[test]
|
||||
@ -359,7 +359,7 @@ documentation has been written. To this end, Rust supports automatically
|
||||
running examples in your documentation. Here's a fleshed-out `src/lib.rs`
|
||||
with examples:
|
||||
|
||||
```{rust,ignore}
|
||||
```rust,ignore
|
||||
//! The `adder` crate provides functions that add numbers to other numbers.
|
||||
//!
|
||||
//! # Examples
|
||||
|
@ -253,7 +253,7 @@ Writing functions with only a few generic types and a small number of trait
|
||||
bounds isn’t too bad, but as the number increases, the syntax gets increasingly
|
||||
awkward:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::fmt::Debug;
|
||||
|
||||
fn foo<T: Clone, K: Clone + Debug>(x: T, y: K) {
|
||||
@ -268,7 +268,7 @@ far right. The bounds are getting in the way.
|
||||
|
||||
Rust has a solution, and it’s called a ‘`where` clause’:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::fmt::Debug;
|
||||
|
||||
fn foo<T: Clone, K: Clone + Debug>(x: T, y: K) {
|
||||
@ -294,7 +294,7 @@ All you need to do is leave off the bounds when defining your type parameters,
|
||||
and then add `where` after the parameter list. For longer lists, whitespace can
|
||||
be added:
|
||||
|
||||
```
|
||||
```rust
|
||||
use std::fmt::Debug;
|
||||
|
||||
fn bar<T, K>(x: T, y: K)
|
||||
@ -311,7 +311,7 @@ This flexibility can add clarity in complex situations.
|
||||
|
||||
`where` is also more powerful than the simpler syntax. For example:
|
||||
|
||||
```
|
||||
```rust
|
||||
trait ConvertTo<Output> {
|
||||
fn convert(&self) -> Output;
|
||||
}
|
||||
|
@ -16,7 +16,7 @@ this is just convention.)
|
||||
|
||||
There’s an alternate form of `vec!` for repeating an initial value:
|
||||
|
||||
```
|
||||
```rust
|
||||
let v = vec![0; 10]; // ten zeroes
|
||||
```
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
Rust also has a `while` loop. It looks like this:
|
||||
|
||||
```{rust}
|
||||
```rust
|
||||
let mut x = 5; // mut x: i32
|
||||
let mut done = false; // mut done: bool
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user