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
Create a canonical trait query for `evaluate_obligation`
This builds on the canonical query machinery introduced in #48411 to introduce a new canonical trait query for `evaluate_obligation` in the trait selector. Also ports most callers of the original `evaluate_obligation` to the new system (except in coherence, which requires support for intercrate mode). Closes#48537.
r? @nikomatsakis
We store the obligation that caused the overflow as part of the OverflowError, and report it at the public API endpoints (rather than in the implementation internals).
This commit emits the `uwtable` attribute to LLVM for platforms that require it
for the allocator shims that we generate to ensure that they can hopefully get
unwound past. This is a stab in the dark at helping
https://bugzilla.mozilla.org/show_bug.cgi?id=1456150 along.
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
Upstream bug reports (rustwasm/wasm-bindgen#119) show that this may be the
culprit of odd crashes/hangs. The linker is a tiny fraction of build time anyway
right now so let's disable it and figure out how to possibly reenable it later
if necessary.
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)
Because they traverse data structures and build up strings, which is
wasted effort if those strings aren't printed.
The patch also removes some now-unnecessary log_enabled! tests at call
sites.
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
