Without this, the `vis` does not wind up in the tree anywhere, and
then we get ICEs because the node-ids it refers to are not present.
The motivation seemed to be documentation, but `ListStem` HIR nodes
are ignored in rustdoc, from what I can tell.
Update books for Rust 2018
This PR:
1. updates all of the books
* I don't know if @Gankro has further plans for the nomicon or not
2. updates the build process because TRPL is only distributing one edition now
3. fixes up the stdlib links
I think that this passes but it's 3:20 am and so I'm sending it in and will fix up anything i missed in the morning.
/cc @alexcrichton for the big beta backport
resolve: Make "empty import canaries" invisible from other crates
Empty imports `use prefix::{};` are desugared into `use prefix::{self as _};` to make sure the prefix is checked for privacy/stability/etc.
This caused issues in cross-crate scenarios because gensyms are lost in crate metadata (the `_` is a gensym).
Fixes https://github.com/rust-lang/rust/issues/55811
rustc: remove {FxHash,Node,DefId,HirId,ItemLocal}{Map,Set} "constructor" fns.
These are cruft left over from a time when `Foo::default()` didn't "just work".
Allow #[must_use] on traits
Addresses https://github.com/rust-lang/rust/issues/55506, but we'll probably want to add it to some library traits like `Iterator` before the issue is considered fixed. Fixes https://github.com/rust-lang/rust/issues/51560.
`#[must_use]` is already permitted on traits, with no effect, so this seems like a bug fix, but I might be overlooking something. This currently warns for `impl Trait` or `dyn Trait` when the `Trait` is `#[must_use]` (although I don't think the latter is currently possible, so it's simply future-proofed).
Add temporary renames to manifests for rustfmt/clippy
This will be part of our strategy for shipping renamed versions of these
components for the Rust 2018 edition.
Closes#55967
Fix stability hole with `static _`
The `underscore_const_names` only gated const items with `_` as the name.
`static _: () = ();` works on beta without feature gates right now, this PR fixes that.
Revert #51601Closes: #55985
Specialization of `StepBy<Range(Inclusive)>` results in an incorrectly behaving code when `step_by` is combined with `skip` or `nth`.
If this will get merged we probably should reopen issues previously closed by #51601 (if there was any).