A few of us [over on the forum](https://users.rust-lang.org/t/string-type-coercion-in-rust/1439) have been tripped up by this distinction, which I don't think is mentioned. It's kind of logical if you read the "Deref coercions" page and squint a bit but I think it would be nice to explain it directly. Here's one way we could clarify it.
Functions such as `fn foo<I: Iterator>(x: I::Item)` would not
render correctly and displayed `I` instead of `I::Item`. Same thing
with `I::Item` appearing in where bounds.
This fixes the bug by using paths for generics.
Fixes#24417
Typo in explanation of difference between stack and heap values.
`baz` is called at the end of a call to `bar` inside another call to `foo`. `baz` takes a copy of the value `e` which should have a value of 9 if following the rest of the stack trace.
This PR fixes this typo and should close#25635.
This is a port of @eddyb's `const-fn` branch. I rebased it, tweaked a few things, and added tests as well as a feature gate. The set of tests is still pretty rudimentary, I'd appreciate suggestions on new tests to write. Also, a double-check that the feature-gate covers all necessary cases.
One question: currently, the feature-gate allows the *use* of const functions from stable code, just not the definition. This seems to fit our usual strategy, and implies that we might (perhaps) allow some constant functions in libstd someday, even before stabilizing const-fn, if we were willing to commit to the existence of const fns but found some details of their impl unsatisfactory.
r? @pnkfelix
`core::cell::Cell<T>` and `core::cell::RefCell<T>` currently implement
`PartialEq` when `T` does, and just defer to comparing `T` values.
There is no reason the same shouldn’t apply to `Eq`.
This enables `#[derive(Eq, PartialEq)]` on e.g.
structs that have a `RefCell` field.
The recent MSVC patch made the build system pass explicit linkers to
rustc, but did not set that up for anything other than MSVC.
This is blocking nightlies.
fixes#25683
I have a very nonscientific measurement of the data via valgrind/massif [here](https://gist.github.com/Manishearth/4c47f15f6835cb3957c4)
I measured the memory usage for both --pretty=expanded and -Z no-trans
It *seems* like there's a 20-25MB decrease during expansion on stage2 librustc; but I'm not quite sure.
r? @eddyb
(have not yet run tests, but it compiles fine, might want to wait before giving r+)
cc @nrc @huon
Reduces pre-trans heap baseline (tested on `fn main() {}`) from 1.2MB to 696kB.
Most of the remaining allocations are used by imported macros.
While it might be possible to also load macros lazily, doing so is non-trivial and this PR doesn't tackle that.
This minimally changes rustdoc's search as described in #25167.
Additionally, I also cleaned up some parts of the JS code.
There is one more change I made: After each result for a primitive type, I added "(Overview of primitive type)". This further differentiates the result from the module (previously, the only difference was that the module's link was blue). I'm not this is the way to go (this seems to be the only place where we do this) and it's no problem for me to remove that commit.
cc @steveklabnik (it concerns docs) and @alexcrichton (who made changes to rustdoc previously)
