rustdoc: remove FIXME about macro redirects
Based on the discussion in #35705, the rustdoc team has determined that macro redirects are here to stay.
Closes#35705
use checked write in `LineWriter` example
The example was wrong because it didn't check the return value of
`write()`, and it didn't flush the buffer before comparing the contents
of the file.
Fixes#51621.
Don't build twice the sanitizers on Linux
This commit is an attempted fix at #50887. It was noticed that on that issue
we're building both x86_64 and i386 versions of libraries, but we only actually
need the x86_64 versions! This hopes that the build race condition exhibited
in #50887 is connected to building both architectures and/or building a lot of
libraries, so this should help us build precisely what we need and no more.
This commit is an attempted fix at #50887. It was noticed that on that issue
we're building both x86_64 and i386 versions of libraries, but we only actually
need the x86_64 versions! This hopes that the build race condition exhibited
in #50887 is connected to building both architectures and/or building a lot of
libraries, so this should help us build precisely what we need and no more.
rustc: Enable `use_extern_macros` in 2018 edition
This was previously enabled via `proc_macro`, but since `proc_macro` is now
stable this is no longer the case. Explicitly include it in the 2018 edition
here.
Allow clippy to be installed with make install
After #51122 clippy is available as a component but doesn't install when building from source.
This PR allows to install clippy with extended tools.
rustc: Fix a suggestion for the `proc_macro` feature
This feature is stable, we shouldn't suggest it any more! Instead suggest the
real feature, `use_extern_macros`.
Amend option.take examples
It wasn't abundantly clear to me what `.take` returned. Perhaps this is a slightly frivolous change, but I think it's an improvement. =)
Apologies if I'm not following proper procedures.
Handle array manually in str case conversion methods
Avoiding the overhead incurred from `String.extend(char.to_lowercase())` showed a notable performance improvement when I benchmarked it.
I tested on these strings:
```rust
ALL_LOWER: "loremipsumdolorsitametduosensibusmnesarchumabcdefgh"
ALL_UPPER: "LOREMIPSUMDOLORSITAMETDUOSENSIBUSMNESARCHUMABCDEFGH"
REALISTIC_UPPER: "LOREM IPSUM DOLOR SIT AMET, DUO SENSIBUS MNESARCHUM"
SIGMAS: "ΣΣΣΣΣ ΣΣΣΣΣ ΣΣΣΣΣ ΣΣΣ ΣΣΣΣ, ΣΣΣ ΣΣΣΣΣΣΣΣ ΣΣΣΣΣΣΣΣΣΣ"
WORD_UPPER: "Lorem Ipsum Dolor Sit Amet, Duo Sensibus Mnesarchum"
```
the performance improvements of `to_lowercase()` were
```
running 10 tests
test tests::all_lower ... bench: 1,752 ns/iter (+/- 49)
test tests::all_lower_new ... bench: 1,266 ns/iter (+/- 15) -28%
test tests::all_upper ... bench: 1,832 ns/iter (+/- 39)
test tests::all_upper_new ... bench: 1,337 ns/iter (+/- 18) -27%
test tests::realistic_upper ... bench: 1,993 ns/iter (+/- 14)
test tests::realistic_upper_new ... bench: 1,445 ns/iter (+/- 22) -27%
test tests::sigmas ... bench: 1,342 ns/iter (+/- 39)
test tests::sigmas_new ... bench: 1,226 ns/iter (+/- 16) -9%
test tests::word_upper ... bench: 1,899 ns/iter (+/- 12)
test tests::word_upper_new ... bench: 1,381 ns/iter (+/- 26) -27%
```
and of `to_uppercase()`
```
running 10 tests
test tests::all_lower ... bench: 1,813 ns/iter (+/- 20)
test tests::all_lower_new ... bench: 1,321 ns/iter (+/- 16) -27%
test tests::all_upper ... bench: 1,629 ns/iter (+/- 22)
test tests::all_upper_new ... bench: 1,241 ns/iter (+/- 9) -24%
test tests::realistic_upper ... bench: 1,670 ns/iter (+/- 24)
test tests::realistic_upper_new ... bench: 1,241 ns/iter (+/- 17) -26%
test tests::sigmas ... bench: 2,053 ns/iter (+/- 20)
test tests::sigmas_new ... bench: 1,753 ns/iter (+/- 23) -15%
test tests::word_upper ... bench: 1,873 ns/iter (+/- 30)
test tests::word_upper_new ... bench: 1,412 ns/iter (+/- 25) -25%
```
I gave up on the more advanced method from #52061 as it wasn't always a clear improvement and would help in even less cases if this PR was merged.
Enable default inlining in platform intrinsics
Since [#28273](https://github.com/rust-lang/rust/issues/28273) has been fixed for quite some time, it might be a good idea to return to default inlining in platform intrinsics.
rustc: Use link_section, not wasm_custom_section
This commit transitions definitions of custom sections on the wasm target from
the unstable `#[wasm_custom_section]` attribute to the
already-stable-for-other-targets `#[link_section]` attribute. Mostly the same
restrictions apply as before, except that this now applies only to statics.
Closes#51088
Avoid most allocations in `Canonicalizer`.
Extra allocations are a significant cost of NLL, and the most common
ones come from within `Canonicalizer`. In particular, `canonical_var()`
contains this code:
indices
.entry(kind)
.or_insert_with(|| {
let cvar1 = variables.push(info);
let cvar2 = var_values.push(kind);
assert_eq!(cvar1, cvar2);
cvar1
})
.clone()
`variables` and `var_values` are `Vec`s. `indices` is a `HashMap` used
to track what elements have been inserted into `var_values`. If `kind`
hasn't been seen before, `indices`, `variables` and `var_values` all get
a new element. (The number of elements in each container is always the
same.) This results in lots of allocations.
In practice, most of the time these containers only end up holding a few
elements. This PR changes them to avoid heap allocations in the common
case, by changing the `Vec`s to `SmallVec`s and only using `indices`
once enough elements are present. (When the number of elements is small,
a direct linear search of `var_values` is as good or better than a
hashmap lookup.)
The changes to `variables` are straightforward and contained within
`Canonicalizer`. The changes to `indices` are more complex but also
contained within `Canonicalizer`. The changes to `var_values` are more
intrusive because they require defining a new type
`SmallCanonicalVarValues` -- which is to `CanonicalVarValues` as
`SmallVec` is to `Vec -- and passing stack-allocated values of that type
in from outside.
All this speeds up a number of NLL "check" builds, the best by 2%.
r? @nikomatsakis
This was previously enabled via `proc_macro`, but since `proc_macro` is now
stable this is no longer the case. Explicitly include it in the 2018 edition
here.
Fix macro parser quadratic complexity in small repeating groups
Observed in #51754, and more easily demonstrated with the following:
```rust
macro_rules! stress {
($($t:tt)+) => { };
}
fn main() {
stress!{
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
// ... 65536 copies of "a" total ...
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
}
}
```
which takes 50 seconds to compile prior to the fix and <1s after.
I hope this has a visible impact on the compile times for real code. (I think it is most likely to affect incremental TT munchers that deal with large inputs, though it depends on how they are written)
For a fuller description of the performance issue: https://github.com/rust-lang/rust/issues/51754#issuecomment-403242159
---
There is no test (yet) because I'm not sure how easily to measure this for regressions.
Enable incremental independent of stage
Previously we'd only do so for stage 0 but with keep-stage
improvements it seems likely that we'll see more developers working in
the stage 1, so we should allow enabling incremental for them.
`BitSlice` fixes
`propagate_bits_into_entry_set_for` and `BitSlice::bitwise` are hot for some benchmarks under NLL. I tried and failed to speed them up. (Increasing the size of `bit_slice::Word` from `usize` to `u128` caused a slowdown, even though decreasing the size of `bitvec::Word` from `u128` to `u64` also caused a slowdown. Weird.)
Anyway, along the way I fixed up several problems in and around the `BitSlice` code.
r? @nikomatsakis
Extra allocations are a significant cost of NLL, and the most common
ones come from within `Canonicalizer`. In particular, `canonical_var()`
contains this code:
indices
.entry(kind)
.or_insert_with(|| {
let cvar1 = variables.push(info);
let cvar2 = var_values.push(kind);
assert_eq!(cvar1, cvar2);
cvar1
})
.clone()
`variables` and `var_values` are `Vec`s. `indices` is a `HashMap` used
to track what elements have been inserted into `var_values`. If `kind`
hasn't been seen before, `indices`, `variables` and `var_values` all get
a new element. (The number of elements in each container is always the
same.) This results in lots of allocations.
In practice, most of the time these containers only end up holding a few
elements. This PR changes them to avoid heap allocations in the common
case, by changing the `Vec`s to `SmallVec`s and only using `indices`
once enough elements are present. (When the number of elements is small,
a direct linear search of `var_values` is as good or better than a
hashmap lookup.)
The changes to `variables` are straightforward and contained within
`Canonicalizer`. The changes to `indices` are more complex but also
contained within `Canonicalizer`. The changes to `var_values` are more
intrusive because they require defining a new type
`SmallCanonicalVarValues` -- which is to `CanonicalVarValues` as
`SmallVec` is to `Vec -- and passing stack-allocated values of that type
in from outside.
All this speeds up a number of NLL "check" builds, the best by 2%.
kennytm
QuietMisdreavus
Esteban Küber
Esteban Küber
Alex Crichton
ljedrz
bors
Corey Farwell
O01eg
Felix Rabe
Ralf Jung
David Wood
Nicholas Nethercote