Rollup merge of #27201 - Ticki:master, r=steveklabnik

Just some small changes.
This commit is contained in:
Steve Klabnik 2015-07-22 12:56:52 -04:00
commit 5665efd60e
2 changed files with 11 additions and 7 deletions

View file

@ -340,7 +340,7 @@ libraries:
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
participates in linkage. From a linkage perspective, the Rust compiler creates
two flavors of artifacts: partial (rlib/staticlib) and final (dylib/binary).
Native dynamic library and framework dependencies are propagated to the final
artifact boundary, while static library dependencies are not propagated at
@ -350,9 +350,9 @@ artifact.
A few examples of how this model can be used are:
* A native build dependency. Sometimes some C/C++ glue is needed when writing
some rust code, but distribution of the C/C++ code in a library format is just
some Rust code, but distribution of the C/C++ code in a library format is just
a burden. In this case, the code will be archived into `libfoo.a` and then the
rust crate would declare a dependency via `#[link(name = "foo", kind =
Rust crate would declare a dependency via `#[link(name = "foo", kind =
"static")]`.
Regardless of the flavor of output for the crate, the native static library
@ -361,7 +361,7 @@ A few examples of how this model can be used are:
* A normal dynamic dependency. Common system libraries (like `readline`) are
available on a large number of systems, and often a static copy of these
libraries cannot be found. When this dependency is included in a rust crate,
libraries cannot be found. When this dependency is included in a Rust crate,
partial targets (like rlibs) will not link to the library, but when the rlib
is included in a final target (like a binary), the native library will be
linked in.

View file

@ -100,10 +100,14 @@ that you normally can not do. Just three. Here they are:
Thats it. Its important that `unsafe` does not, for example, turn off the
borrow checker. Adding `unsafe` to some random Rust code doesnt change its
semantics, it wont just start accepting anything.
semantics, it wont just start accepting anything. But it will let you write
things that _do_ break some of the rules.
But it will let you write things that _do_ break some of the rules. Lets go
over these three abilities in order.
You will also encounter the `unsafe` keyword when writing bindings to foreign
(non-Rust) interfaces. You're encouraged to write a safe, native Rust interface
around the methods provided by the library.
Lets go over the basic three abilities listed, in order.
## Access or update a `static mut`