Auto merge of #26150 - steveklabnik:rollup, r=steveklabnik
- Successful merges: #26111, #26125, #26129, #26131, #26132, #26133, #26134, #26136, #26140, #26144 - Failed merges:
This commit is contained in:
commit
ac67354392
9 changed files with 47 additions and 18 deletions
|
|
@ -1367,7 +1367,6 @@ Traits can include default implementations of methods, as in:
|
|||
```
|
||||
trait Foo {
|
||||
fn bar(&self);
|
||||
|
||||
fn baz(&self) { println!("We called baz."); }
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -64,7 +64,10 @@ unsafe {
|
|||
|
||||
[unsafe]: unsafe.html
|
||||
|
||||
Furthermore, any type stored in a `static` must be `Sync`.
|
||||
Furthermore, any type stored in a `static` must be `Sync`, and may not have
|
||||
a [`Drop`][drop] implementation.
|
||||
|
||||
[drop]: drop.html
|
||||
|
||||
# Initializing
|
||||
|
||||
|
|
@ -78,7 +81,3 @@ Almost always, if you can choose between the two, choose `const`. It’s pretty
|
|||
rare that you actually want a memory location associated with your constant,
|
||||
and using a const allows for optimizations like constant propagation not only
|
||||
in your crate but downstream crates.
|
||||
|
||||
A const can be thought of as a `#define` in C: it has metadata overhead but it
|
||||
has no runtime overhead. “Should I use a #define or a static in C,” is largely
|
||||
the same question as whether you should use a const or a static in Rust.
|
||||
|
|
|
|||
|
|
@ -674,9 +674,13 @@ let handles: Vec<_> = philosophers.into_iter().map(|p| {
|
|||
|
||||
Finally, inside of our `map()`/`collect()` loop, we call `table.clone()`. The
|
||||
`clone()` method on `Arc<T>` is what bumps up the reference count, and when it
|
||||
goes out of scope, it decrements the count. You’ll notice we can introduce a
|
||||
new binding to `table` here, and it will shadow the old one. This is often used
|
||||
so that you don’t need to come up with two unique names.
|
||||
goes out of scope, it decrements the count. This is needed so that we know how
|
||||
many references to `table` exist across our threads. If we didn’t have a count,
|
||||
we wouldn’t know how to deallocate it.
|
||||
|
||||
You’ll notice we can introduce a new binding to `table` here, and it will
|
||||
shadow the old one. This is often used so that you don’t need to come up with
|
||||
two unique names.
|
||||
|
||||
With this, our program works! Only two philosophers can eat at any one time,
|
||||
and so you’ll get some output like this:
|
||||
|
|
|
|||
|
|
@ -342,8 +342,10 @@ Note that frameworks are only available on OSX targets.
|
|||
The different `kind` values are meant to differentiate how the native library
|
||||
participates in linkage. From a linkage perspective, the rust compiler creates
|
||||
two flavors of artifacts: partial (rlib/staticlib) and final (dylib/binary).
|
||||
Native dynamic libraries and frameworks are propagated to the final artifact
|
||||
boundary, while static libraries are not propagated at all.
|
||||
Native dynamic library and framework dependencies are propagated to the final
|
||||
artifact boundary, while static library dependencies are not propagated at
|
||||
all, because the static libraries are integrated directly into the subsequent
|
||||
artifact.
|
||||
|
||||
A few examples of how this model can be used are:
|
||||
|
||||
|
|
|
|||
|
|
@ -86,8 +86,8 @@ impl Circle {
|
|||
# Chaining method calls
|
||||
|
||||
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`.
|
||||
original example, `foo.bar().baz()`? This is called ‘method chaining’. Let’s
|
||||
look at an example:
|
||||
|
||||
```rust
|
||||
struct Circle {
|
||||
|
|
|
|||
|
|
@ -154,6 +154,31 @@ match x {
|
|||
|
||||
This prints `Got an int!`.
|
||||
|
||||
If you’re using `if` with multiple patterns, the `if` applies to both sides:
|
||||
|
||||
```rust
|
||||
let x = 4;
|
||||
let y = false;
|
||||
|
||||
match x {
|
||||
4 | 5 if y => println!("yes"),
|
||||
_ => println!("no"),
|
||||
}
|
||||
```
|
||||
|
||||
This prints `no`, because the `if` applies to the whole of `4 | 5`, and not to
|
||||
just the `5`, In other words, the the precedence of `if` behaves like this:
|
||||
|
||||
```text
|
||||
(4 | 5) if y => ...
|
||||
```
|
||||
|
||||
not this:
|
||||
|
||||
```text
|
||||
4 | (5 if y) => ...
|
||||
```
|
||||
|
||||
# ref and ref mut
|
||||
|
||||
If you want to get a [reference][ref], use the `ref` keyword:
|
||||
|
|
|
|||
|
|
@ -151,9 +151,9 @@ As it turns out, there are rules.
|
|||
|
||||
Here’s the rules about borrowing in Rust:
|
||||
|
||||
First, any borrow must last for a smaller scope than the owner. Second, you may
|
||||
have one or the other of these two kinds of borrows, but not both at the same
|
||||
time:
|
||||
First, any borrow must last for a scope no greater than that of the owner.
|
||||
Second, you may have one or the other of these two kinds of borrows, but not
|
||||
both at the same time:
|
||||
|
||||
* one or more references (`&T`) to a resource.
|
||||
* exactly one mutable reference (`&mut T`)
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ implement `Convert` like so:
|
|||
|
||||
```rust
|
||||
impl Convert<uint> for int { ... } // int -> uint
|
||||
impl Convert<int> for uint { ... } // uint -> uint
|
||||
impl Convert<int> for uint { ... } // uint -> int
|
||||
```
|
||||
|
||||
Now imagine there is some code like the following:
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ pub const HEX_WIDTH: usize = 10;
|
|||
// 2. For each element of the path, emit the length plus the element
|
||||
// 3. End the path with "E"
|
||||
//
|
||||
// For example, "_ZN4testE" => "test" and "_ZN3foo3bar" => "foo::bar".
|
||||
// For example, "_ZN4testE" => "test" and "_ZN3foo3barE" => "foo::bar".
|
||||
//
|
||||
// We're the ones printing our backtraces, so we can't rely on anything else to
|
||||
// demangle our symbols. It's *much* nicer to look at demangled symbols, so
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue