RangeFrom should have an infinite size_hint
Before,
```rust
(0..).take(4).size_hint() == (0, Some(4))
```
With this change,
```rust
(0..).take(4).size_hint() == (4, Some(4))
```
Clarify the docs for align_of and its variants
It's okay to have unaligned raw pointers and then use `ptr::write_unaligned` and `ptr::read_unaligned`.
However, using unaligned `&T` and `&mut T` would be undefined behavior.
The current documentation seems to indicate that everything has to be aligned, but in reality only references do. This PR changes the text of docs accordingly.
r? @sfackler
Explain why a closure is `FnOnce` in closure errors.
Issue: #42065
@nikomatsakis Am I going the right direction with this?
~~I am stuck in a few bits:~~
~~1. How to trace the code to get the upvar instead of the original variable's span?~~
~~2. How to find the node id of the upvar where the move occured?~~
Clarify docs on implementing Into.
This was suggested by @dtolnay in #40380.
This explicitly clarifies in what circumstances you should implement `Into` instead of `From`.
rust-src: include everything needed to compile libstd with jemalloc
I am not very happy about all this `Path::new`, but did not find a nice way to avoid it. Also, this shouldn't be very performance-critical.
With this patch, rust-src-1.19.0-dev.tar.gz grows from 1.4 to 3.1 MiB (new uncompressed size: 15.5 MiB). Not great, but shipping incomplete sources is also not great, and this is still much smaller than pre-#41546. Excluding the entire `src/jemalloc/test` does not work, unfortunately; there is a file in there that is needed to build libstd. (And anyway there's just 190 KiB uncompressed left in that folder.)
In principle, we could try excluding the Rust test suite directories (that would be `libcore/tests` and `libcollection/tests`). I don't know enough about how this component is used to judge whether that would cause any problems. Anyway this is just 600 KiB uncompressed.
Fixes#41952
incr.comp.: Remove DepGraph::write() and its callers
After months of yak shaving, we are finally there `:)`
The existence of `DepGraph::write()` was one of the two main ways for introducing cycles into the dep-graph -- something we need to avoid in the future. The other way, re-opening nodes to add more edges, is next on the list.
r? @nikomatsakis
incr.comp.: Track expanded spans instead of FileMaps.
This PR removes explicit tracking of FileMaps in response to #42101. The reasoning behind being able to just *not* track access to FileMaps is similar to why we don't track access to the `DefId->DefPath` map:
1. One can only get ahold of a `Span` value by accessing the HIR (for local things) or a `metadata::schema::Entry` (for things from external crates).
2. For both of these things we compute a hash that incorporates the *expanded spans*, that is, what we hash is in the (FileMap independent) format `filename:line:col`.
3. Consequently, everything that emits a span should already be tracked via its dependency to something that has the span included in its hash and changes would be detected via that hash.
One caveat here is that we have to be conservative when exporting things in metadata. A crate can be built without debuginfo and would thus by default not incorporate most spans into the metadata hashes. However, a downstream crate can make an inline copy of things in the upstream crate and span changes in the upstream crate would then go undetected, even if the downstream uses them (e.g. by emitting debuginfo for an inlined function). For this reason, we always incorporate spans into metadata hashes for now (there might be more efficient ways to handle this safely when red-green tracking is implemented).
r? @nikomatsakis
Override size_hint and propagate ExactSizeIterator for iter::StepBy
Generally useful, but also a prerequisite for moving a bunch of unit tests off `Range*::step_by`.
A small non-breaking subset of https://github.com/rust-lang/rust/pull/42110 (which I closed).
Includes two small documentation changes @ivandardi requested on that PR.
r? @alexcrichton
Translate array drop glue using MIR
I was a bit lazy here and used a usize-based index instead of a pointer iteration. Do you think this is important @eddyb?
r? @eddyb
