diff --git a/src/backend/implicit-caller-location.md b/src/backend/implicit-caller-location.md index e0a12415e..a621b57b1 100644 --- a/src/backend/implicit-caller-location.md +++ b/src/backend/implicit-caller-location.md @@ -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 diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index cce9fac49..a2eeb6029 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -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`. diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md index 111f6858d..af3cd7ce2 100644 --- a/src/building/compiler-documenting.md +++ b/src/building/compiler-documenting.md @@ -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 diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index f4d783f5d..29d10edd0 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -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. ## 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 diff --git a/src/building/new-target.md b/src/building/new-target.md index 0bd200908..eea01e9cc 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -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 diff --git a/src/building/suggested.md b/src/building/suggested.md index fd2c00baa..08858507f 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -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 diff --git a/src/contributing.md b/src/contributing.md index 180197ddc..e835eef84 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -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`. diff --git a/src/getting-started.md b/src/getting-started.md index 9d5db4b05..055551c60 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -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` diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 549a9cd05..1b4f827d4 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -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`. diff --git a/src/profile-guided-optimization.md b/src/profile-guided-optimization.md index fb897e901..03198fb1a 100644 --- a/src/profile-guided-optimization.md +++ b/src/profile-guided-optimization.md @@ -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 diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 33d001f39..8c6050da2 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -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 diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index ab3bf1b30..d44e6679b 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -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. diff --git a/src/rustdoc.md b/src/rustdoc.md index 1a3cf7019..b37c15808 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -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 diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 73edc3be5..73875bceb 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -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). diff --git a/src/tests/adding.md b/src/tests/adding.md index 538860f65..c74f6cec4 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -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 diff --git a/src/tests/intro.md b/src/tests/intro.md index 0f517f871..125e2c931 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -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 diff --git a/src/tests/running.md b/src/tests/running.md index 44561f6f2..1a6805132 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -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 diff --git a/src/walkthrough.md b/src/walkthrough.md index c2a1308b6..9963692c7 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -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