Partial future-proofing for Box<T, A>
In some ways, this is similar to @eddyb's PR #47043 that went stale, but doesn't cover everything. Notably, this still leaves Box internalized as a pointer in places, so practically speaking, only ZSTs can be practically added to the Box type with the changes here (the compiler ICEs otherwise).
The Box type is not changed here, that's left for the future because I want to test that further first, but this puts things in place in a way that hopefully will make things easier.
Rollup of 7 pull requests
Successful merges:
- #49707 (Add "the Rustc book")
- #50222 (Bump bootstrap compiler to 2018-04-24)
- #50227 (Fix ICE with erroneous `impl Trait` in a trait impl)
- #50229 (Add setting to go to item if there is only one result)
- #50231 (Add more doc aliases)
- #50246 (Make dump_{alloc,allocs,local}() no-ops when tracing is disabled.)
- #49894 (Rename InternedString to LocalInternedString and introduce a new thread-safe InternedString)
Failed merges:
Rename InternedString to LocalInternedString and introduce a new thread-safe InternedString
This is an allocation-free alternative to https://github.com/rust-lang/rust/pull/46972.
Make dump_{alloc,allocs,local}() no-ops when tracing is disabled.
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.
This is a big win for the Debug and Opt runs of coercions, tuple-stress, html5ever, and encoding.
```
coercions-opt
avg: -7.8% min: -14.8% max: 0.1%
coercions
avg: -8.0% min: -12.8% max: 0.1%
tuple-stress
avg: -7.2% min: -10.8% max: -0.7%
tuple-stress-opt
avg: -6.9% min: -10.7% max: 0.6%
html5ever
avg: -4.6% min: -7.3% max: -0.3%
encoding
avg: -2.4% min: -4.5% max: 0.1%
html5ever-opt
avg: -2.7% min: -4.2% max: -0.2%
encoding-opt
avg: -1.4% min: -2.4% max: 0.0%
```
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
