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.
The first one in particular results in Rust not being able to build itself
if it is installed. The latter two shouldn't be necessary, and should only
be included if they are actually going to be used.
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.
