Rename src/libstd to library/std etc.

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

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`.

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

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.
 
 <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

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

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

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`.
 

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`
 

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`.