Add "the Rustc book"
This PR introduces a new book into the documentation, "The rustc book". We already have books for Cargo, and for Rustdoc, rustc should have some too. This book is focused on *users* of rustc, and provides a nice place to write documentation for users.
I haven't put content here, but plan on scaffolding it out very soon, and wanted this PR open for a few discussions first. One of those is "what exactly should said TOC be?" I plan on having a proposed one up tomorrow, but figured I'd let people know to start thinking about it now.
The big one is that we also will want to put https://github.com/rust-lang-nursery/rustc-guide in-tree as well, and the naming is... tough. I'm proposing:
* doc.rust-lang.org/rustc is "The Rustc book", to mirror the other tools' books.
* doc.rust-lang.org/rustc-contribution is "The Rustc contribution guide", and contains that book
@nikomatsakis et al, any thoughts on this? I'm not attached to it in particular, but had to put something together to get this discussion going. I think mirroring the other tools is a good idea for this work, but am not sure where exactly that leaves yours.
Fixes https://github.com/rust-docs/team/issues/11
drop elaboration should reveal all
This used to happen implicitly through the normalization function; but we now keep the param-env as is, which seems less surprising.
cc #49685
r? @eddyb
Treat repr(Rust) univariant fieldless enums as ZSTs
This makes all those enums be represented the same way:
```rust
enum A1 { B1 }
enum A2 { B2 = 0 }
enum A3 { B3, C3(!) }
```
Related to #15747.
Cc @rust-lang/wg-codegen @rust-lang/lang
Rollup of 4 pull requests
Successful merges:
- #50177 (mark std::str::replace(,n) as #[must_use])
- #50207 (Hash EntryKind::AssociatedConst const data)
- #50214 (Js improvements)
- #50219 (Added missing `.` in docs.)
Failed merges:
- #50229 (Add setting to go to item if there is only one result)
Allow variant discriminant initializers to refer to other initializer…
…s of the same enum
r? @eddyb
fixes the 2.4 failure of https://github.com/rust-lang/rust/issues/49765
cc @durka @retep998
Allow crate:: in local paths
Currently if you want to use `crate` locally you have to do `::crate::`. This shouldn't be necessary
(will fix up tests later)
r? @petrochenkov
Introduce compile-pass
r? @alexcrichton
The plan is to move things that cannot fail (no assert, unwrap, etc) out so we don't have to run them, and in the long term we can also stop running LLVM for them.
Out of 3215 tests...
```
Language Files Lines Code Comments Blanks
Rust 3215 119254 64688 35135 19431
```
16% of them has an empty main (which is already moved in this PR).
```
grep -rnPzl 'fn main\(\)\s*{\s*}' | xargs rg --files-without-match cfg | wc -l
547
```
And only 50% of the tests contains assertions:
```
rg -e assert -e unwrap -e expect -e panic -l | wc -l
1600
```
The remainder is likely able to get moved, but they need check by a human so I didn't touch them in PR.
cc @rust-lang/compiler
* [ ] Update documentation
