Auto merge of #50097 - glandium:box_free, r=nikomatsakis
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.
- #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)
Rollup merge of #49707 - steveklabnik:rustc-book, r=QuietMisdreavus
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.
Auto merge of #48995 - aravind-pg:canonical-query, r=nikomatsakis
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.
Refactor overflow handling in traits::select to propagate overflow instead of aborting eagerly
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).
Auto merge of #49321 - ishitatsuyuki:compile-pass, r=alexcrichton
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.
Auto merge of #50110 - oli-obk:warn_all_the_constants, r=estebank
Warn on all erroneous constants
fixes #49791
fixes #47054
@Zoxc this PR triggers the nondeterministic errors of https://github.com/rust-lang/rust/pull/49950#issuecomment-383074959 really often (at least on stage1).
Auto merge of #50100 - Manishearth:edition-path-lint, r=nikomatsakis
Edition breakage lint for absolute paths starting with modules
We plan to enable `extern_absolute_paths` in the 2018 edition. To allow for that, folks must transition their paths in a previous edition to the new one. This makes paths which import module contents via `use module::` or `::module::` obsolete, and we must edition-lint these.
https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205?u=manishearth is the current plan for paths.
Mike Hommey [Fri, 20 Apr 2018 01:24:53 +0000 (10:24 +0900)]
Switch box_free to take the destructured contents of Box
As of now, Box only contains a Unique pointer, so this is the sole
argument to box_free. Consequently, we remove the code supporting
the previous box_free signature. We however keep the old definition
for bootstrapping purpose.
Auto merge of #49986 - zofrex:better-derived-argument-names, r=Manishearth
Provide better names for builtin deriving-generated attributes
First attempt at fixing #49967
Not in love with any choices here, don't be shy if you aren't happy with anything :)
I've tested that this produces nicer names in documentation, and that it no longer has issues conflicting with constants with the same name. (I guess we _could_ make a test for that... unsure if that would be valuable)
In all cases I took the names from the methods as declared in the relevant trait.
In some cases I had to prepend the names with _ otherwise there were errors about un-used variables. I'm uneasy with the inconsistency... do they all need to be like that? Is there a way to generate an alternate impl or use a different name (`_`?) in the cases where the arguments are not used?
Lastly the gensym addition to Ident I implemented largely as suggested, but I want to point out it's a little circuitous (at least, as far as I understand it). `cx.ident_of(name)` is just `Ident::from_str`, so we create an Ident then another Ident from it. `Ident::with_empty_ctxt(Symbol::gensym(string))` may or may not be equivalent, I don't know if it's important to intern it _then_ gensym it. It seems like either we could use that, or if we do want a new method to make this convenient, it could be on Ident instead (`from_str_gensymed`?)
A comment already stated that this test should be disabled, but its
`should_fail` is not enough to excuse it from a compiler panic. Remove
it from the `revisions` list to disable it harder.
The prior check causes abstract unix domain sockets to return AddressKind::Unnamed instead of AddressKind::Abstract on Android.
Other than the immediately proceeding comment "macOS seems to return a len of 16 and a zeroed sun_path for unnamed addresses" the check as-implemented does not seem to have alternative explanation. I couldn't find an alternative explanation while stepping though git blame. I suspect the AddressKind::Unnamed nonzero check should instead be if macos, length 16, and zeroed array. @sfackler could you comment on this, the code as-is is the same from your initial addition of abstract uds support.