Attribute drop code to block's closing brace, instead of the line where the allocation was done.
Attribute function epilogues to function body's closing brace, rather than the function header.
Detect local-rebuild by just the MAJOR.MINOR version
A new point-release shouldn't change any language semantics, so a local
stage0 that matches MAJOR.MINOR version should still be considered a
local-rebuild as far as `--cfg stageN` features go.
e.g. `1.14.0` should be considered a local-rebuild for any `1.14.X`.
(Bootstrap keys used to be an issue too, until #37265.)
Don't enqueue onto a disabled dep_graph.
This commit guards all calls to `DepGraphThreadData::enqueue` with a
check to make sure it is enabled. This avoids some useless allocation
and vector manipulations when it is disabled (i.e. when incremental
compilation is off) which improves speed by 1--2% on most of the
rustc-benchmarks.
This commit has an observable functional change: when the dep_graph is
disabled its `shadow_graph` will no longer receive messages. This should
be ok because these message are only used when debug assertions are
enabled.
r? @nikomatsakis
This commit changes the parameters of `deflate` to do faster,
lower-quality compression. For the compression of LLVM bytecode -- which
is the main use of `deflate_bytes` -- it makes compression almost twice
as fast while the size of the compressed files is only ~2% worse.
prefer `if let` to match with `None => { }` arm in some places
In #34268 (8531d581), we replaced matches of None to the unit value `()`
with `if let`s in places where it was deemed that this made the code
unambiguously clearer and more idiomatic. In #34638 (d37edef9), we did
the same for matches of None to the empty block `{}`.
A casual observer, upon seeing these commits fly by, might suppose that
the matter was then settled, that no further pull requests on this
utterly trivial point of style could or would be made. Unless ...
It turns out that sometimes people write the empty block with a space in
between the braces. Who knew?
This commit enables by default passing the `-C debuginfo=1` argument to the
compiler for the stable, beta, and nightly release channels. A new configure
option was also added, `--enable-debuginfo-lines`, to enable this behavior in
developer builds as well.
Closes#36452
alloc_slice in TypedArena
Added `TypedArena::alloc_slice`, and moved from using `TypedArena<Vec<T>>` to `TypedArena<T>`.
`TypedArena::alloc_slice` is implemented by copying the slices elements into the typed arena, requiring that `T: Copy` when using it. We allocate a new chunk when there's insufficient space remaining in the previous chunk, and we cannot resize the old chunk in place. This is non-optimal, since we may waste allocated space when allocating (especially longer) slices, but is considered good enough for the time being.
This change also reduces heap fragmentation, since the arena now directly stores objects instead of storing the Vec's length and pointer to its contents.
Performance:
```
futures-rs-test 5.048s vs 5.061s --> 0.997x faster (variance: 1.028x, 1.020x)
helloworld 0.284s vs 0.295s --> 0.963x faster (variance: 1.207x, 1.189x)
html5ever-2016- 8.396s vs 8.208s --> 1.023x faster (variance: 1.019x, 1.036x)
hyper.0.5.0 5.768s vs 5.797s --> 0.995x faster (variance: 1.027x, 1.028x)
inflate-0.1.0 5.213s vs 5.069s --> 1.028x faster (variance: 1.008x, 1.022x)
issue-32062-equ 0.428s vs 0.467s --> 0.916x faster (variance: 1.188x, 1.015x)
issue-32278-big 1.949s vs 2.010s --> 0.970x faster (variance: 1.112x, 1.049x)
jld-day15-parse 1.795s vs 1.877s --> 0.956x faster (variance: 1.037x, 1.015x)
piston-image-0. 13.554s vs 13.522s --> 1.002x faster (variance: 1.019x, 1.020x)
rust-encoding-0 2.489s vs 2.465s --> 1.010x faster (variance: 1.047x, 1.086x)
syntex-0.42.2 34.646s vs 34.593s --> 1.002x faster (variance: 1.007x, 1.005x)
syntex-0.42.2-i 17.181s vs 17.163s --> 1.001x faster (variance: 1.004x, 1.004x)
```
r? @eddyb
A new point-release shouldn't change any language semantics, so a local
stage0 that matches MAJOR.MINOR version should still be considered a
local-rebuild as far as `--cfg stageN` features go.
e.g. `1.14.0` should be considered a local-rebuild for any `1.14.X`.
(Bootstrap keys used to be an issue too, until #37265.)
macros: improve `$crate`
This PR refactors the implementation of `$crate` so that
- `$crate` is only allowed at the start of a path (like `super`),
- we can make `$crate` work with inter-crate re-exports (groundwork for macro modularization), and
- we can support importing macros from an extern crate that is not declared at the crate root (also groundwork for macro modularization).
This is a [breaking-change]. For example, the following would break:
```rust
fn foo() {}
macro_rules! m { () => {
$crate foo $crate () $crate $crate;
//^ Today, `$crate` is allowed just about anywhere in unexported macros.
} }
fn main() {
m!();
}
```
r? @nrc
Optimize `write_metadata`.
`write_metadata` currently generates metadata unnecessarily in some
cases, and also compresses it unnecessarily in some cases. This commit
fixes that. It speeds up three of the rustc-benchmarks by 1--4%.
r? @eddyb, who deserves much of the credit because he (a) identified the problem from the profile data I provided in #37086, and (b) explained to me how to fix it. Thank you, @eddyb!
Allow bootstrapping without a key. Fixes#36548
This will make it easier for packagers to bootstrap rustc when they happen
to have a bootstrap compiler with a slightly different version number.
It's not ok for anything other than the build system to set this environment variable.
r? @alexcrichton
std::collections: Reexport libcollections's range module
This is overdue, even if range and RangeArgument is still unstable.
The stability attributes are the same ones as the other unstable item
(Bound) here, they don't seem to matter.
ICH: Use 128-bit Blake2b hash instead of 64-bit SipHash for incr. comp. fingerprints
This PR makes incr. comp. hashes 128 bits wide in order to push collision probability below a threshold that we need to worry about. It also replaces SipHash, which has been mentioned multiple times as not being built for fingerprinting, with the [BLAKE2b hash function](https://blake2.net/), an improved version of the BLAKE sha-3 finalist.
I was worried that using a cryptographic hash function would make ICH computation noticeably slower, but after doing some performance tests, I'm not any more. Most of the time BLAKE2b is actually faster than using two SipHashes (in order to get 128 bits):
```
SipHash
libcore: 0.199 seconds
libstd: 0.090 seconds
BLAKE2b
libcore: 0.162 seconds
libstd: 0.078 seconds
```
If someone can prove that something like MetroHash128 provides a comparably low collision probability as BLAKE2, I'm happy to switch. But for now we are at least not taking a performance hit.
I also suggest that we throw out the sha-256 implementation in the compiler and replace it with BLAKE2, since our sha-256 implementation is two to three times slower than the BLAKE2 implementation in this PR (cc @alexcrichton @eddyb @brson)
r? @nikomatsakis (although there's not much incr. comp. specific in here, so feel free to re-assign)
