Rename `src/libstd` to `library/std` etc. (#815)
This commit is contained in:
Yuki Okushi
GitHub
parent
38aef99f68
commit
68a2b034c5
|
|
@ -17,7 +17,7 @@ fn main() {
|
|||
}
|
||||
```
|
||||
|
||||
Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore:
|
||||
Prior to Rust 1.42, panics like this `unwrap()` printed a location in core:
|
||||
|
||||
```
|
||||
$ rustc +1.41.0 example.rs; example.exe
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ The `stage2` compiler is the one distributed with `rustup` and all other
|
|||
install methods. However, it takes a very long time to build because one must
|
||||
first build the new compiler with an older compiler and then use that to
|
||||
build the new compiler with itself. For development, you usually only want
|
||||
the `stage1` compiler: `x.py build --stage 1 src/libstd`.
|
||||
the `stage1` compiler: `x.py build --stage 1 library/std`.
|
||||
|
||||
## Complications of bootstrapping
|
||||
|
||||
|
|
@ -128,7 +128,7 @@ The following tables indicate the outputs of various stage actions:
|
|||
|-----------------------------------------------------------|----------------------------------------------|
|
||||
| `beta` extracted | `build/HOST/stage0` |
|
||||
| `stage0` builds `bootstrap` | `build/bootstrap` |
|
||||
| `stage0` builds `libtest`/`libstd` | `build/HOST/stage0-std/TARGET` |
|
||||
| `stage0` builds `test`/`std` | `build/HOST/stage0-std/TARGET` |
|
||||
| copy `stage0-std` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` |
|
||||
| `stage0` builds `rustc` with `stage0-sysroot` | `build/HOST/stage0-rustc/HOST` |
|
||||
| copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` |
|
||||
|
|
@ -143,7 +143,7 @@ The following tables indicate the outputs of various stage actions:
|
|||
| copy (uplift) `stage0-rustc` executable to `stage1` | `build/HOST/stage1/bin` |
|
||||
| copy (uplift) `stage0-codegen` to `stage1` | `build/HOST/stage1/lib` |
|
||||
| copy (uplift) `stage0-sysroot` to `stage1` | `build/HOST/stage1/lib` |
|
||||
| `stage1` builds `libtest`/`libstd` | `build/HOST/stage1-std/TARGET` |
|
||||
| `stage1` builds `test`/`std` | `build/HOST/stage1-std/TARGET` |
|
||||
| copy `stage1-std` (HOST only) | `build/HOST/stage1/lib/rustlib/HOST` |
|
||||
| `stage1` builds `rustc` | `build/HOST/stage1-rustc/HOST` |
|
||||
| copy `stage1-rustc` (except executable) | `build/HOST/stage1/lib/rustlib/HOST` |
|
||||
|
|
@ -155,7 +155,7 @@ The following tables indicate the outputs of various stage actions:
|
|||
|--------------------------------------------------------|-----------------------------------------------------------------|
|
||||
| copy (uplift) `stage1-rustc` executable | `build/HOST/stage2/bin` |
|
||||
| copy (uplift) `stage1-sysroot` | `build/HOST/stage2/lib and build/HOST/stage2/lib/rustlib/HOST` |
|
||||
| `stage2` builds `libtest`/`libstd` (not HOST targets) | `build/HOST/stage2-std/TARGET` |
|
||||
| `stage2` builds `test`/`std` (not HOST targets) | `build/HOST/stage2-std/TARGET` |
|
||||
| copy `stage2-std` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` |
|
||||
| `stage2` builds `rustdoc` | `build/HOST/stage2-tools/HOST` |
|
||||
| copy `rustdoc` | `build/HOST/stage2/bin` |
|
||||
|
|
@ -196,21 +196,21 @@ later copied into stage2 as well (both the compiler's `libdir` and the
|
|||
This `std` is pretty much necessary for any useful work with the compiler.
|
||||
Specifically, it's used as the `std` for programs compiled by the newly compiled
|
||||
compiler (so when you compile `fn main() { }` it is linked to the last `std`
|
||||
compiled with `x.py build --stage 1 src/libstd`).
|
||||
compiled with `x.py build --stage 1 library/std`).
|
||||
|
||||
The `rustc` generated by the stage0 compiler is linked to the freshly-built
|
||||
`libstd`, which means that for the most part only `std` needs to be cfg-gated,
|
||||
`std`, which means that for the most part only `std` needs to be cfg-gated,
|
||||
so that `rustc` can use featured added to std immediately after their addition,
|
||||
without need for them to get into the downloaded beta. The `libstd` built by the
|
||||
without need for them to get into the downloaded beta. The `std` built by the
|
||||
`stage1/bin/rustc` compiler, also known as "stage1 std artifacts", is not
|
||||
necessarily ABI-compatible with that compiler.
|
||||
That is, the `rustc` binary most likely could not use this `std` itself.
|
||||
It is however ABI-compatible with any programs that the `stage1/bin/rustc`
|
||||
binary builds (including itself), so in that sense they're paired.
|
||||
|
||||
This is also where `--keep-stage 1 src/libstd` comes into play. Since most
|
||||
This is also where `--keep-stage 1 library/std` comes into play. Since most
|
||||
changes to the compiler don't actually change the ABI, once you've produced a
|
||||
`libstd` in stage 1, you can probably just reuse it with a different compiler.
|
||||
`std` in stage 1, you can probably just reuse it with a different compiler.
|
||||
If the ABI hasn't changed, you're good to go, no need to spend the time
|
||||
recompiling that `std`.
|
||||
`--keep-stage` simply assumes the previous compile is fine and copies those
|
||||
|
|
@ -254,12 +254,12 @@ variables that are used. If you are trying to run an intermediate version of
|
|||
manually. Otherwise, you get an error like the following:
|
||||
|
||||
```text
|
||||
thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', src/libcore/result.rs:1165:5
|
||||
thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', library/core/src/result.rs:1165:5
|
||||
```
|
||||
|
||||
If `./stageN/bin/rustc` gives an error about environment variables, that
|
||||
usually means something is quite wrong -- or you're trying to compile e.g.
|
||||
`librustc` or `libstd` or something that depends on environment variables. In
|
||||
`librustc` or `std` or something that depends on environment variables. In
|
||||
the unlikely case that you actually need to invoke rustc in such a situation,
|
||||
you can find the environment variable values by adding the following flag to
|
||||
your `x.py` command: `--on-fail=print-env`.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ and then it documents the files.
|
|||
```bash
|
||||
./x.py doc src/doc/book
|
||||
./x.py doc src/doc/nomicon
|
||||
./x.py doc src/doc/book src/libstd
|
||||
./x.py doc src/doc/book library/std
|
||||
```
|
||||
|
||||
Much like individual tests or building certain components you can build only
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ assertions = true
|
|||
# `true`, because an unoptimized rustc with debugging
|
||||
# enabled becomes *unusably slow* (e.g. rust-lang/rust#24840
|
||||
# reported a 25x slowdown) and bootstrapping the supposed
|
||||
# "maximally debuggable" environment (notably libstd) takes
|
||||
# "maximally debuggable" environment (notably std) takes
|
||||
# hours to build.
|
||||
#
|
||||
debug = true
|
||||
|
|
@ -92,7 +92,7 @@ One thing to keep in mind is that `rustc` is a _bootstrapping_
|
|||
compiler. That is, since `rustc` is written in Rust, we need to use an
|
||||
older version of the compiler to compile the newer version. In
|
||||
particular, the newer version of the compiler and some of the artifacts needed
|
||||
to build it, such as `libstd` and other tooling, may use some unstable features
|
||||
to build it, such as `std` and other tooling, may use some unstable features
|
||||
internally, requiring a specific version which understands these unstable
|
||||
features.
|
||||
|
||||
|
|
@ -176,16 +176,16 @@ Once you've created a config.toml, you are now ready to run
|
|||
probably the best "go to" command for building a local rust:
|
||||
|
||||
```bash
|
||||
./x.py build -i src/libstd
|
||||
./x.py build -i library/std
|
||||
```
|
||||
|
||||
This may *look* like it only builds `libstd`, but that is not the case.
|
||||
This may *look* like it only builds `std`, but that is not the case.
|
||||
What this command does is the following:
|
||||
|
||||
- Build `libstd` using the stage0 compiler (using incremental)
|
||||
- Build `std` using the stage0 compiler (using incremental)
|
||||
- Build `librustc` using the stage0 compiler (using incremental)
|
||||
- This produces the stage1 compiler
|
||||
- Build `libstd` using the stage1 compiler (cannot use incremental)
|
||||
- Build `std` using the stage1 compiler (cannot use incremental)
|
||||
|
||||
This final product (stage1 compiler + libs built using that compiler)
|
||||
is what you need to build other rust programs (unless you use `#![no_std]` or
|
||||
|
|
@ -201,7 +201,7 @@ stage1 libraries. This is because incremental only works when you run
|
|||
the *same compiler* twice in a row. In this case, we are building a
|
||||
*new stage1 compiler* every time. Therefore, the old incremental
|
||||
results may not apply. **As a result, you will probably find that
|
||||
building the stage1 `libstd` is a bottleneck for you** -- but fear not,
|
||||
building the stage1 `std` is a bottleneck for you** -- but fear not,
|
||||
there is a (hacky) workaround. See [the section on "recommended
|
||||
workflows"](./suggested.md) below.
|
||||
|
||||
|
|
@ -211,23 +211,23 @@ build. The **full** `rustc` build (what you get if you say `./x.py build
|
|||
|
||||
- Build `librustc` and `rustc` with the stage1 compiler.
|
||||
- The resulting compiler here is called the "stage2" compiler.
|
||||
- Build `libstd` with stage2 compiler.
|
||||
- Build `std` with stage2 compiler.
|
||||
- Build `librustdoc` and a bunch of other things with the stage2 compiler.
|
||||
|
||||
<a name=toolchain></a>
|
||||
|
||||
## Build specific components
|
||||
|
||||
Build only the libcore library
|
||||
- Build only the core library
|
||||
|
||||
```bash
|
||||
./x.py build src/libcore
|
||||
./x.py build library/core
|
||||
```
|
||||
|
||||
Build the libcore and libproc_macro library only
|
||||
- Build the core and proc_macro libraries only
|
||||
|
||||
```bash
|
||||
./x.py build src/libcore src/libproc_macro
|
||||
./x.py build library/core library/proc_macro
|
||||
```
|
||||
|
||||
Sometimes you might just want to test if the part you’re working on can
|
||||
|
|
@ -277,11 +277,11 @@ in other sections:
|
|||
|
||||
- Building things:
|
||||
- `./x.py build` – builds everything using the stage 1 compiler,
|
||||
not just up to `libstd`
|
||||
not just up to `std`
|
||||
- `./x.py build --stage 2` – builds the stage2 compiler
|
||||
- Running tests (see the [section on running tests](../tests/running.html) for
|
||||
more details):
|
||||
- `./x.py test src/libstd` – runs the `#[test]` tests from `libstd`
|
||||
- `./x.py test library/std` – runs the `#[test]` tests from `std`
|
||||
- `./x.py test src/test/ui` – runs the `ui` test suite
|
||||
- `./x.py test src/test/ui/const-generics` - runs all the tests in
|
||||
the `const-generics/` subdirectory of the `ui` test suite
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ cross-compile `rustc`:
|
|||
```
|
||||
DESTDIR=/path/to/install/in \
|
||||
./x.py install -i --stage 1 --host aarch64-apple-darwin.json --target aarch64-apple-darwin \
|
||||
src/librustc src/libstd
|
||||
src/librustc library/std
|
||||
```
|
||||
|
||||
If your target specification is already available in the bootstrap
|
||||
|
|
|
|||
|
|
@ -58,13 +58,13 @@ don't work (but that is easily detected and fixed).
|
|||
|
||||
The sequence of commands you want is as follows:
|
||||
|
||||
- Initial build: `./x.py build -i src/libstd`
|
||||
- Initial build: `./x.py build -i library/std`
|
||||
- As [documented above](#command), this will build a functional
|
||||
stage1 compiler as part of running all stage0 commands (which include
|
||||
building a `libstd` compatible with the stage1 compiler) as well as the
|
||||
building a `std` compatible with the stage1 compiler) as well as the
|
||||
first few steps of the "stage 1 actions" up to "stage1 (sysroot stage1)
|
||||
builds libstd".
|
||||
- Subsequent builds: `./x.py build -i src/libstd --keep-stage 1`
|
||||
builds std".
|
||||
- Subsequent builds: `./x.py build -i library/std --keep-stage 1`
|
||||
- Note that we added the `--keep-stage 1` flag here
|
||||
|
||||
As mentioned, the effect of `--keep-stage 1` is that we just *assume* that the
|
||||
|
|
|
|||
|
|
@ -364,7 +364,7 @@ You can find documentation style guidelines in [RFC 1574][rfc1574].
|
|||
In many cases, you don't need a full `./x.py doc --stage 2`, which will build
|
||||
the entire stage 2 compiler and compile the various books published on
|
||||
[doc.rust-lang.org][docs]. When updating documentation for the standard library,
|
||||
first try `./x.py doc src/libstd`. If that fails, or if you need to
|
||||
first try `./x.py doc library/std`. If that fails, or if you need to
|
||||
see the output from the latest version of `rustdoc`, add `--stage 1`.
|
||||
Results should appear in `build/$TARGET/crate-docs`.
|
||||
|
||||
|
|
|
|||
|
|
@ -175,9 +175,9 @@ should still read the rest of the section:
|
|||
| Command | When to use it |
|
||||
| --- | --- |
|
||||
| `x.py check` | Quick check to see if things compile; rust-analyzer can run this automatically for you |
|
||||
| `x.py build --stage 0 [src/libstd]` | Build only the standard library, without building the compiler |
|
||||
| `x.py build src/libstd` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough |
|
||||
| `x.py build --keep-stage 1 src/libstd` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) |
|
||||
| `x.py build --stage 0 [library/std]` | Build only the standard library, without building the compiler |
|
||||
| `x.py build library/std` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough |
|
||||
| `x.py build --keep-stage 1 library/std` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) |
|
||||
| `x.py test [--keep-stage 1]` | Run the test suite using the stage1 compiler |
|
||||
| `x.py test --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. |
|
||||
| `x.py build --stage 2 src/rustc` | Do a full 2-stage build. You almost never want to do this. |
|
||||
|
|
@ -203,10 +203,10 @@ For most contributions, you only need to build stage 1, which saves a lot of tim
|
|||
|
||||
```sh
|
||||
# Build the compiler (stage 1)
|
||||
./x.py build src/libstd
|
||||
./x.py build library/std
|
||||
|
||||
# Subsequent builds
|
||||
./x.py build --keep-stage 1 src/libstd
|
||||
./x.py build --keep-stage 1 library/std
|
||||
```
|
||||
|
||||
This will take a while, especially the first time. Be wary of accidentally
|
||||
|
|
@ -294,10 +294,10 @@ stage 0, which uses the current beta compiler.
|
|||
```
|
||||
|
||||
```sh
|
||||
./x.py test --stage 0 src/libstd
|
||||
./x.py test --stage 0 library/std
|
||||
```
|
||||
|
||||
(The same works for `src/liballoc`, `src/libcore`, etc.)
|
||||
(The same works for `library/alloc`, `library/core`, etc.)
|
||||
|
||||
### Building and Testing `rustdoc`
|
||||
|
||||
|
|
|
|||
|
|
@ -2,14 +2,14 @@
|
|||
|
||||
#### Step 1: Invocation of the `panic!` macro.
|
||||
|
||||
There are actually two panic macros - one defined in `libcore`, and one defined in `libstd`.
|
||||
This is due to the fact that code in `libcore` can panic. `libcore` is built before `libstd`,
|
||||
but we want panics to use the same machinery at runtime, whether they originate in `libcore`
|
||||
or `libstd`.
|
||||
There are actually two panic macros - one defined in `core`, and one defined in `std`.
|
||||
This is due to the fact that code in `core` can panic. `core` is built before `std`,
|
||||
but we want panics to use the same machinery at runtime, whether they originate in `core`
|
||||
or `std`.
|
||||
|
||||
##### libcore definition of panic!
|
||||
##### core definition of panic!
|
||||
|
||||
The `libcore` `panic!` macro eventually makes the following call (in `src/libcore/panicking.rs`):
|
||||
The `core` `panic!` macro eventually makes the following call (in `library/core/src/panicking.rs`):
|
||||
|
||||
```rust
|
||||
// NOTE This function never crosses the FFI boundary; it's a Rust-to-Rust call
|
||||
|
|
@ -29,13 +29,13 @@ Actually resolving this goes through several layers of indirection:
|
|||
to set the actual symbol name to `rust_begin_unwind`.
|
||||
|
||||
Note that `panic_impl` is declared in an `extern "Rust"` block,
|
||||
which means that libcore will attempt to call a foreign symbol called `rust_begin_unwind`
|
||||
which means that core will attempt to call a foreign symbol called `rust_begin_unwind`
|
||||
(to be resolved at link time)
|
||||
|
||||
2. In `src/libstd/panicking.rs`, we have this definition:
|
||||
2. In `library/std/src/panicking.rs`, we have this definition:
|
||||
|
||||
```rust
|
||||
/// Entry point of panic from the libcore crate.
|
||||
/// Entry point of panic from the core crate.
|
||||
#[cfg(not(test))]
|
||||
#[panic_handler]
|
||||
#[unwind(allowed)]
|
||||
|
|
@ -47,18 +47,18 @@ pub fn begin_panic_handler(info: &PanicInfo<'_>) -> ! {
|
|||
The special `panic_handler` attribute is resolved via `src/librustc_middle/middle/lang_items`.
|
||||
The `extract` function converts the `panic_handler` attribute to a `panic_impl` lang item.
|
||||
|
||||
Now, we have a matching `panic_handler` lang item in the `libstd`. This function goes
|
||||
through the same process as the `extern { fn panic_impl }` definition in `libcore`, ending
|
||||
up with a symbol name of `rust_begin_unwind`. At link time, the symbol reference in `libcore`
|
||||
will be resolved to the definition of `libstd` (the function called `begin_panic_handler` in the
|
||||
Now, we have a matching `panic_handler` lang item in the `std`. This function goes
|
||||
through the same process as the `extern { fn panic_impl }` definition in `core`, ending
|
||||
up with a symbol name of `rust_begin_unwind`. At link time, the symbol reference in `core`
|
||||
will be resolved to the definition of `std` (the function called `begin_panic_handler` in the
|
||||
Rust source).
|
||||
|
||||
Thus, control flow will pass from libcore to std at runtime. This allows panics from `libcore`
|
||||
Thus, control flow will pass from core to std at runtime. This allows panics from `core`
|
||||
to go through the same infrastructure that other panics use (panic hooks, unwinding, etc)
|
||||
|
||||
##### libstd implementation of panic!
|
||||
##### std implementation of panic!
|
||||
|
||||
This is where the actual panic-related logic begins. In `src/libstd/panicking.rs`,
|
||||
This is where the actual panic-related logic begins. In `library/std/src/panicking.rs`,
|
||||
control passes to `rust_panic_with_hook`. This method is responsible
|
||||
for invoking the global panic hook, and checking for double panics. Finally,
|
||||
we call `__rust_start_panic`, which is provided by the panic runtime.
|
||||
|
|
@ -84,13 +84,13 @@ Finally, we call `__rust_start_panic` with this `usize`. We have now entered the
|
|||
|
||||
#### Step 2: The panic runtime
|
||||
|
||||
Rust provides two panic runtimes: `libpanic_abort` and `libpanic_unwind`. The user chooses
|
||||
Rust provides two panic runtimes: `panic_abort` and `panic_unwind`. The user chooses
|
||||
between them at build time via their `Cargo.toml`
|
||||
|
||||
`libpanic_abort` is extremely simple: its implementation of `__rust_start_panic` just aborts,
|
||||
`panic_abort` is extremely simple: its implementation of `__rust_start_panic` just aborts,
|
||||
as you would expect.
|
||||
|
||||
`libpanic_unwind` is the more interesting case.
|
||||
`panic_unwind` is the more interesting case.
|
||||
|
||||
In its implementation of `__rust_start_panic`, we take the `usize`, convert
|
||||
it back to a `*mut &mut dyn BoxMeUp`, dereference it, and call `box_me_up`
|
||||
|
|
@ -99,10 +99,11 @@ itself (a `*mut (dyn Send + Any)`): that is, a raw pointer to the actual value
|
|||
provided by the user who called `panic!`.
|
||||
|
||||
At this point, the platform-independent code ends. We now call into
|
||||
platform-specific unwinding logic (e.g `libunwind`). This code is
|
||||
platform-specific unwinding logic (e.g `unwind`). This code is
|
||||
responsible for unwinding the stack, running any 'landing pads' associated
|
||||
with each frame (currently, running destructors), and transferring control
|
||||
to the `catch_unwind` frame.
|
||||
|
||||
Note that all panics either abort the process or get caught by some call to `catch_unwind`:
|
||||
in `src/libstd/rt.rs`, the call to the user-provided `main` function is wrapped in `catch_unwind`.
|
||||
in `library/std/src/rt.rs`, the call to the user-provided
|
||||
`main` function is wrapped in `catch_unwind`.
|
||||
|
|
|
|||
|
|
@ -108,10 +108,10 @@ data needs some infrastructure in place.
|
|||
In the case of LLVM, these runtime components are implemented in
|
||||
[compiler-rt][compiler-rt-profile] and statically linked into any instrumented
|
||||
binaries.
|
||||
The `rustc` version of this can be found in `src/libprofiler_builtins` which
|
||||
The `rustc` version of this can be found in `library/profiler_builtins` which
|
||||
basically packs the C code from `compiler-rt` into a Rust crate.
|
||||
|
||||
In order for `libprofiler_builtins` to be built, `profiler = true` must be set
|
||||
In order for `profiler_builtins` to be built, `profiler = true` must be set
|
||||
in `rustc`'s `config.toml`.
|
||||
|
||||
[compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/master/compiler-rt/lib/profile
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ address [issue 42678](https://github.com/rust-lang/rust/issues/42678).
|
|||
Compile the compiler, up to at least stage 1:
|
||||
|
||||
```
|
||||
x.py build src/libstd
|
||||
x.py build library/std
|
||||
```
|
||||
|
||||
### 2. Run `rustc`, with flags
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ documentation in `test.rs`, but instead of going through the full clean and
|
|||
render process, it runs a much simpler crate walk to grab *just* the
|
||||
hand-written documentation. Combined with the aforementioned
|
||||
"`find_testable_code`" in `html/markdown.rs`, it builds up a collection of
|
||||
tests to run before handing them off to the libtest test runner. One notable
|
||||
tests to run before handing them off to the test test runner. One notable
|
||||
location in `test.rs` is the function `make_test`, which is where hand-written
|
||||
doctests get transformed into something that can be executed.
|
||||
|
||||
|
|
|
|||
|
|
@ -32,11 +32,11 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
|
|||
|
||||
* Use `./x.py build` to make a usable
|
||||
rustdoc you can run on other projects.
|
||||
* Add `src/libtest` to be able to use `rustdoc --test`.
|
||||
* Add `library/test` to be able to use `rustdoc --test`.
|
||||
* If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1`
|
||||
previously, then after the previous build command, `cargo +local doc` will
|
||||
Just Work.
|
||||
* Use `./x.py doc --stage 1 src/libstd` to use this rustdoc to generate the
|
||||
* Use `./x.py doc --stage 1 library/std` to use this rustdoc to generate the
|
||||
standard library docs.
|
||||
* The completed docs will be available in `build/$TARGET/doc/std`, though the
|
||||
bundle is meant to be used as though you would copy out the `doc` folder to
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ writing, the next stable release (i.e. what is currently beta) was
|
|||
|
||||
Next search for the feature string (in this case, `pub_restricted`)
|
||||
in the codebase to find where it appears. Change uses of
|
||||
`#![feature(XXX)]` from the `libstd` and any rustc crates to be
|
||||
`#![feature(XXX)]` from the `std` and any rustc crates to be
|
||||
`#![cfg_attr(bootstrap, feature(XXX))]`. This includes the feature-gate
|
||||
only for stage0, which is built using the current beta (this is
|
||||
needed because the feature is still unstable in the current beta).
|
||||
|
|
|
|||
|
|
@ -378,8 +378,8 @@ The following strings replace their corresponding values:
|
|||
Additionally, the following changes are made:
|
||||
|
||||
- Line and column numbers for paths in `$SRC_DIR` are replaced with `LL:CC`.
|
||||
For example, `/path/to/rust/src/libcore/clone.rs:122:8` is replaced with
|
||||
`$SRC_DIR/libcore/clone.rs:LL:COL`.
|
||||
For example, `/path/to/rust/library/core/src/clone.rs:122:8` is replaced with
|
||||
`$SRC_DIR/core/src/clone.rs:LL:COL`.
|
||||
|
||||
Note: The line and column numbers for `-->` lines pointing to the test are
|
||||
*not* normalized, and left as-is. This ensures that the compiler continues
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ details.
|
|||
- `rustdoc` – tests for rustdoc, making sure that the generated files
|
||||
contain the expected documentation.
|
||||
- `*-fulldeps` – same as above, but indicates that the test depends
|
||||
on things other than `libstd` (and hence those things must be built)
|
||||
on things other than `std` (and hence those things must be built)
|
||||
|
||||
## Other Tests
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ including:
|
|||
include typical Rust `#[test]` unittests. Under the hood, `x.py` will run
|
||||
`cargo test` on each package to run all the tests.
|
||||
|
||||
Example: `./x.py test src/libstd`
|
||||
Example: `./x.py test library/std`
|
||||
|
||||
- **Doc tests** – Example code embedded within Rust documentation is executed
|
||||
via `rustdoc --test`. Examples:
|
||||
|
|
@ -90,7 +90,7 @@ including:
|
|||
`./x.py test src/doc` – Runs `rustdoc --test` for all documentation in
|
||||
`src/doc`.
|
||||
|
||||
`./x.py test --doc src/libstd` – Runs `rustdoc --test` on the standard
|
||||
`./x.py test --doc library/std` – Runs `rustdoc --test` on the standard
|
||||
library.
|
||||
|
||||
- **Link checker** – A small tool for verifying `href` links within
|
||||
|
|
|
|||
|
|
@ -68,19 +68,19 @@ Likewise, you can test a single file by passing its path:
|
|||
### Run tests on the standard library
|
||||
|
||||
```bash
|
||||
./x.py test src/libstd
|
||||
./x.py test library/std
|
||||
```
|
||||
|
||||
### Run the tidy script and tests on the standard library
|
||||
|
||||
```bash
|
||||
./x.py test tidy src/libstd
|
||||
./x.py test tidy library/std
|
||||
```
|
||||
|
||||
### Run tests on the standard library using a stage 1 compiler
|
||||
|
||||
```bash
|
||||
> ./x.py test src/libstd
|
||||
> ./x.py test library/std
|
||||
```
|
||||
|
||||
By listing which test suites you want to run you avoid having to run
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ before, not all of these are needed for every type of contribution.
|
|||
- **Implementation** Implement your idea unstably in the compiler. You can
|
||||
find the original implementation [here][impl1].
|
||||
- **Possibly iterate/refine** As the community gets experience with your
|
||||
feature on the nightly compiler and in `libstd`, there may be additional
|
||||
feature on the nightly compiler and in `std`, there may be additional
|
||||
feedback about design choice that might be adjusted. This particular feature
|
||||
went [through][impl2] a [number][impl3] of [iterations][impl4].
|
||||
- **Stabilization** When your feature has baked enough, a rust team member may
|
||||
|
|
|
|||
Loading…
Reference in New Issue