Windows tests can often deadlock if a child thread continues after the main
thread and then panics, and a `println!` executed in a child thread after the
main thread has exited is at risk of panicking.
This flag indicates that when files are being replaced or added to archives (the
`r` flag) that the new file should not be inserted if it is not newer than the
file that already exists in the archive. The compiler never actually has a use
case of *not* wanting to insert a file because it already exists, and this
causes rlibs to not be updated in some cases when the compiler was re-run too
quickly.
Closes#18913
This flag indicates that when files are being replaced or added to archives (the
`r` flag) that the new file should not be inserted if it is not newer than the
file that already exists in the archive. The compiler never actually has a use
case of *not* wanting to insert a file because it already exists, and this
causes rlibs to not be updated in some cases when the compiler was re-run too
quickly.
Closes#18913
The caching essentially eliminates "stability checking" time (my attempt to clean-up junk got tangled up with stability, so I added the caching while I was at it).
r? @eddyb
A regression was introduced by commit 7b1916d253#25612. Negative signed integer literals less than -9223372036854775808i64 were no longer properly reported as #[warn(overflowing_literals)].
Also adding missing test cases to test/compile-fail/lint-type-overflow.rs which could have detected the regression.
Further explanation:
The expression `(negative && v > max as u64 + 1)` relies on the fact that algebraically speaking `-min == max + 1` to avoid negation and removing the need for `min` completely.
If i128 or i256 are ever added, it should also work for these types without requiring a change to `min != i64::MIN &&` also simplifying maintenance.
r? @pnkfelix
In all other places the IDs of link references are without spaces (and explicitly set).
These are just some cleanups I did for the PDF version.
r? @steveklabnik
I'm not sure why `core` is on but it's blocking the playpen. Doesn't seem to be needed but I'm not sure. It's not on the playpen template and playpen works on release and nightly.
Seems easier to understand without `take()`.
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.
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
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)
Alex Crichton
bors
Ariel Ben-Yehuda
Michael Layzell
Björn Steinbrink
econoplas
Pascal Hertleif
Thomas Karpiniec
Tshepang Lekhonkhobe
Alex Stokes
Oliver Schneider
