Auto merge of #28782 - steveklabnik:rollup, r=steveklabnik
- Successful merges: #28753, #28760, #28764, #28770, #28771, #28772 - Failed merges:
This commit is contained in:
commit
d14dba1227
@ -76,8 +76,13 @@ An identifier is any nonempty Unicode[^non_ascii_idents] string of the following
|
||||
[^non_ascii_idents]: Non-ASCII characters in identifiers are currently feature
|
||||
gated. This is expected to improve soon.
|
||||
|
||||
- The first character has property `XID_start`
|
||||
- The remaining characters have property `XID_continue`
|
||||
Either
|
||||
* The first character has property `XID_start`
|
||||
* The remaining characters have property `XID_continue`
|
||||
Or
|
||||
* The first character is `_`
|
||||
* The identifier is more than one character, `_` alone is not an identifier
|
||||
* The remaining characters have property `XID_continue`
|
||||
|
||||
that does _not_ occur in the set of [keywords][keywords].
|
||||
|
||||
@ -3937,11 +3942,11 @@ initialized; this is enforced by the compiler.
|
||||
The Rust compiler supports various methods to link crates together both
|
||||
statically and dynamically. This section will explore the various methods to
|
||||
link Rust crates together, and more information about native libraries can be
|
||||
found in the [ffi section of the book][ffi].
|
||||
found in the [FFI section of the book][ffi].
|
||||
|
||||
In one session of compilation, the compiler can generate multiple artifacts
|
||||
through the usage of either command line flags or the `crate_type` attribute.
|
||||
If one or more command line flag is specified, all `crate_type` attributes will
|
||||
If one or more command line flags are specified, all `crate_type` attributes will
|
||||
be ignored in favor of only building the artifacts specified by command line.
|
||||
|
||||
* `--crate-type=bin`, `#[crate_type = "bin"]` - A runnable executable will be
|
||||
@ -3987,7 +3992,7 @@ Note that these outputs are stackable in the sense that if multiple are
|
||||
specified, then the compiler will produce each form of output at once without
|
||||
having to recompile. However, this only applies for outputs specified by the
|
||||
same method. If only `crate_type` attributes are specified, then they will all
|
||||
be built, but if one or more `--crate-type` command line flag is specified,
|
||||
be built, but if one or more `--crate-type` command line flags are specified,
|
||||
then only those outputs will be built.
|
||||
|
||||
With all these different kinds of outputs, if crate A depends on crate B, then
|
||||
|
@ -4,14 +4,6 @@ By default, `std` is linked to every Rust crate. In some contexts,
|
||||
this is undesirable, and can be avoided with the `#![no_std]`
|
||||
attribute attached to the crate.
|
||||
|
||||
```ignore
|
||||
// a minimal library
|
||||
#![crate_type="lib"]
|
||||
#![feature(no_std)]
|
||||
#![no_std]
|
||||
# // fn main() {} tricked you, rustdoc!
|
||||
```
|
||||
|
||||
Obviously there's more to life than just libraries: one can use
|
||||
`#[no_std]` with an executable, controlling the entry point is
|
||||
possible in two ways: the `#[start]` attribute, or overriding the
|
||||
@ -21,7 +13,10 @@ The function marked `#[start]` is passed the command line parameters
|
||||
in the same format as C:
|
||||
|
||||
```rust
|
||||
#![feature(lang_items, start, no_std, libc)]
|
||||
# #![feature(libc)]
|
||||
#![feature(lang_items)]
|
||||
#![feature(start)]
|
||||
#![feature(no_std)]
|
||||
#![no_std]
|
||||
|
||||
// Pull in the system libc library for what crt0.o likely requires
|
||||
@ -47,11 +42,13 @@ with `#![no_main]` and then create the appropriate symbol with the
|
||||
correct ABI and the correct name, which requires overriding the
|
||||
compiler's name mangling too:
|
||||
|
||||
```ignore
|
||||
```rust
|
||||
# #![feature(libc)]
|
||||
#![feature(no_std)]
|
||||
#![feature(lang_items)]
|
||||
#![feature(start)]
|
||||
#![no_std]
|
||||
#![no_main]
|
||||
#![feature(lang_items, start)]
|
||||
|
||||
extern crate libc;
|
||||
|
||||
@ -92,19 +89,24 @@ instead.
|
||||
|
||||
The core library has very few dependencies and is much more portable than the
|
||||
standard library itself. Additionally, the core library has most of the
|
||||
necessary functionality for writing idiomatic and effective Rust code.
|
||||
necessary functionality for writing idiomatic and effective Rust code. When
|
||||
using `#![no_std]`, Rust will automatically inject the `core` crate, just like
|
||||
we do for `std` when we’re using it.
|
||||
|
||||
As an example, here is a program that will calculate the dot product of two
|
||||
vectors provided from C, using idiomatic Rust practices.
|
||||
|
||||
```ignore
|
||||
#![feature(lang_items, start, no_std, core, libc)]
|
||||
```rust
|
||||
# #![feature(libc)]
|
||||
#![feature(lang_items)]
|
||||
#![feature(start)]
|
||||
#![feature(no_std)]
|
||||
#![feature(core)]
|
||||
#![feature(core_slice_ext)]
|
||||
#![feature(raw)]
|
||||
#![no_std]
|
||||
|
||||
# extern crate libc;
|
||||
extern crate core;
|
||||
|
||||
use core::prelude::*;
|
||||
extern crate libc;
|
||||
|
||||
use core::mem;
|
||||
|
||||
|
@ -41,8 +41,8 @@ and just consider the local variables we’re allocating. So in this case, when
|
||||
This is automatically handled for you, as you can see; we didn’t have to write
|
||||
any special Rust code or anything.
|
||||
|
||||
When the function is over, its stack frame gets deallocated. This happens
|
||||
automatically, we didn’t have to do anything special here.
|
||||
When the function exits, its stack frame gets deallocated. This happens
|
||||
automatically as well.
|
||||
|
||||
That’s all there is for this simple program. The key thing to understand here
|
||||
is that stack allocation is very, very fast. Since we know all the local
|
||||
|
@ -218,7 +218,7 @@ impl PartialOrd for Ordering {
|
||||
///
|
||||
/// The comparison must satisfy, for all `a`, `b` and `c`:
|
||||
///
|
||||
/// - antisymmetry: if `a < b` then `!(a > b)` and vice versa; and
|
||||
/// - antisymmetry: if `a < b` then `!(a > b)`, as well as `a > b` implying `!(a < b)`; and
|
||||
/// - transitivity: `a < b` and `b < c` implies `a < c`. The same must hold for both `==` and `>`.
|
||||
///
|
||||
/// Note that these requirements mean that the trait itself must be implemented symmetrically and
|
||||
|
Loading…
Reference in New Issue
Block a user