compute and cache HIR hashes at beginning
This avoids the compile-time overhead of computing them twice. It also fixes
an issue where the hash computed after typeck is differen than the hash before,
because typeck mutates the def-map in place.
Fixes#35549.
Fixes#35593.
Some performance measurements suggest this `HashesMap` is very small in memory (unobservable via `-Z time-passes`) and very cheap to construct. I do see some (very minor) performance wins in the incremental case after the first run -- the first run costs more because loading the dep-graph didn't have any hashing to do in that case. Example timings from two runs of `libsyntex-syntax` -- the (1) indicates first run, (2) indicates second run, and (*) indicates both together:
| Phase | Master | Branch |
| ---- | ---- | ---- |
| compute_hashes_map (1) | N/A | 0.343 |
| load_dep_graph (1) | 0 | 0 |
| serialize dep graph (1) | 4.190 | 3.920 |
| total (1) | 4.190 | 4.260 |
| compute_hashes_map (2) | N/A | 0.344 |
| load_dep_graph (2) | 0.592 | 0.252 |
| serialize dep graph (2) | 4.119 | 3.779 |
| total (2) | 4.71 | 4.375 |
| total (*) | 8.9 | 8.635 |
r? @michaelwoerister
Implement 1581 (FusedIterator)
* [ ] Implement on patterns. See https://github.com/rust-lang/rust/issues/27721#issuecomment-239638642.
* [ ] Handle OS Iterators. A bunch of iterators (`Args`, `Env`, etc.) in libstd wrap platform specific iterators. The current ones all appear to be well-behaved but can we assume that future ones will be?
* [ ] Does someone want to audit this? On first glance, all of the iterators on which I implemented `FusedIterator` appear to be well-behaved but there are a *lot* of them so a second pair of eyes would be nice.
* I haven't touched rustc internal iterators (or the internal rand) because rustc doesn't actually call `fuse()`.
* `FusedIterator` can't be implemented on `std::io::{Bytes, Chars}`.
Closes: #35602 (Tracking Issue)
Implements: rust-lang/rfcs#1581
Implement `CoerceUnsized` for `{Cell, RefCell, UnsafeCell}`
These impls are analogous to the one for `NonZero`. It's occasionally useful to be able to coerce the cell types when they're being used inside another abstraction. See Manishearth/rust-gc#17 for an example.
r? @eddyb
cstring: avoid excessive growth just to 0-terminate
Based on following what happens in CString::new("string literal"):
1. Using `Into<Vec<u8>>`, a Vec is allocated with capacity exactly equal
to the string's input length.
2. By `v.push(0)`, the Vec is grown to twice capacity, since it was full.
3. By `v.into_boxed_slice()`, the Vec capacity is shrunk to fit the length again.
If we use `.reserve_exact(1)` just before the push, then we avoid the
capacity doubling that we're going to have to shrink anyway.
Growing by just 1 byte means that the step (2) is less likely to have to
move the memory to a larger allocation chunk, and that the step (3) does
not have to reallocate.
Addresses part of #35838
Check that executable file is in-tree before failing tidy check
I silenced stdout and stderr for ls-files, not sure if that's appropriate (is `make tidy` intended to give debugging information)? Otherwise it prints each file it find to stdout/stderr, which currently prints nothing (only executable files are checked).
I have not done major testing regarding the behavior of ls-files when the file is ignored, but judging by the man page everything should be fine.
I've duplicated the code which makes the path git-friendly from the `Cargo.lock` checking code; I can extract that into a common helper if wanted (it's only two lines).
Fixes#35689.
