BTreeMap: disentangle Drop implementation from IntoIter
No longer require every `BTreeMap` to dig up its last leaf edge before dying. This speeds up the `clone_` benchmarks by 25% for normal keys and values (far less for huge values).
r? `@Mark-Simulacrum`
The issue was that the `kind, id` override was previously only being
considered for the disambiguator check, not the privacy check. This uses
the same ID for both.
Unfortunately, this can't currently be tested. The problem is that we
need the file to be compiled first to then be used as dependency, which
cannot be done currently unfortunately in the rustdoc test suites.
Example:
```rust
// name this file "foo.rs"
/// ```
/// let x = foo::foo();
/// ```
pub fn foo() {}
```
If you run `rustdoc --test foo.rs`, you'll get:
```
running 1 test
test foo.rs - foo (line 1) ... FAILED
failures:
---- foo.rs - foo (line 1) stdout ----
error[E0463]: can't find crate for `foo`
--> foo.rs:0:1
|
2 | extern crate foo;
| ^^^^^^^^^^^^^^^^^ can't find crate
```
If a test were possible, it would look something like
````rust
#![crate_name = "mod"]
#![crate_type = "lib"]
//! ```
//! // NOTE: requires that the literal string 'mod' appears in the doctest for
//! // the bug to appear
//! assert_eq!(1, 1);
//! ```
````
Reduce log level used by tracing instrumentation from info to debug
Restore log level to debug to avoid make info log level overly verbose (the uses of instrument attribute modified there, were for the most part a replacement for `debug!`; one use was novel).
Optimize Vec::retain
Use `copy_non_overlapping` instead of `swap` to reduce memory writes, like what we've done in #44355 and `String::retain`.
#48065 already tried to do this optimization but it is reverted in #67300 due to bad codegen of `DrainFilter::drop`.
This PR re-implement the drop-then-move approach. I did a [benchmark](https://gist.github.com/oxalica/3360eec9376f22533fcecff02798b698) on small-no-drop, small-need-drop, large-no-drop elements with different predicate functions. It turns out that the new implementation is >20% faster in average for almost all cases. Only 2/24 cases are slower by 3% and 5%. See the link above for more detail.
I think regression in may-panic cases is due to drop-guard preventing some optimization. If it's permitted to leak elements when predicate function of element's `drop` panic, the new implementation should be almost always faster than current one.
I'm not sure if we should leak on panic, since there is indeed an issue (#52267) complains about it before.
resolve: Cleanup visibility resolution for enum variants and trait items
by always delegating it to `fn resolve_visibility`.
Also remove some special treatment of visibility on enum variants and trait items remaining from pre-`pub(restricted)` times.
Special treatment like this was necessary before `pub(restricted)` had been implemented and only two visibilities existed - `pub` and non-`pub`.
Now it's no longer necessary and the desired behavior follows from `pub(restricted)`-style visibilities naturally assigned to enum variants and trait items.
We now allow two new casts:
- mut array reference to mut ptr. Example:
let mut x: [usize; 2] = [0, 0];
let p = &mut x as *mut usize;
We allow casting const array references to const pointers so not
allowing mut references to mut pointers was inconsistent.
- mut array reference to const ptr. Example:
let mut x: [usize; 2] = [0, 0];
let p = &mut x as *const usize;
This was similarly inconsistent as we allow casting mut references to
const pointers.
Existing test 'vector-cast-weirdness' updated to test both cases.
Fixes#24151
update RLS and rustfmt
Fixes#81582 and fixes#81583
r? `@Xanewok`
I was originally surprised by the size of lockfile diff, though after looking at the RLS changes it makes a bit more sense to me now
Allow unstable features in some PGO benchmarks
Some of the benchmarks we're using for PGO require unstable features (such as compiling the standard library and some rustc-perf benchmarks), breaking CI on the beta and stable branches. For the past two releases we cherry-picked a commit directly onto the beta branch that unconditionally sets `RUSTC_BOOTSTRAP=1`, and this PR backports a similar change to the master branch.
The difference between this commit and the one we backported previously (483c1a83ca) is that this is more scoped in which benchmarks we allow unstable features, to prevent unintentionally enabling unstable features.
r? `@Mark-Simulacrum`
Update cargo
5 commits in 34170fcd6e0947808a1ac63ac85ffc0da7dace2f..ab64d1393b5b77c66b6534ef5023a1b89ee7bf64
2021-02-04 15:52:52 +0000 to 2021-02-10 00:19:10 +0000
- Allow `true` and `false` as options for `strip` option (rust-lang/cargo#9153)
- Change git dependencies to use `HEAD` by default (rust-lang/cargo#9133)
- appendix auth gcm link to new repo (which is xplat) (rust-lang/cargo#9152)
- Fix warnings of the new non_fmt_panic lint (rust-lang/cargo#9148)
- Fix panic with doc collision orphan. (rust-lang/cargo#9142)
Rename HIR UnOp variants
This renames the variants in HIR UnOp from
enum UnOp {
UnDeref,
UnNot,
UnNeg,
}
to
enum UnOp {
Deref,
Not,
Neg,
}
Motivations:
- This is more consistent with the rest of the code base where most enum
variants don't have a prefix.
- These variants are never used without the `UnOp` prefix so the extra
`Un` prefix doesn't help with readability. E.g. we don't have any
`UnDeref`s in the code, we only have `UnOp::UnDeref`.
- MIR `UnOp` type variants don't have a prefix so this is more
consistent with MIR types.
- "un" prefix reads like "inverse" or "reverse", so as a beginner in
rustc code base when I see "UnDeref" what comes to my mind is
something like `&*` instead of just `*`.
Use format string in bootstrap panic instead of a string directly
This fixes the following warning when compiling with nightly:
```
warning: panic message is not a string literal
--> src/bootstrap/builder.rs:1515:24
|
1515 | panic!(out);
| ^^^
|
= note: `#[warn(non_fmt_panic)]` on by default
= note: this is no longer accepted in Rust 2021
help: add a "{}" format string to Display the message
|
1515 | panic!("{}", out);
| ^^^^^
help: or use std::panic::panic_any instead
|
1515 | std::panic::panic_any(out);
| ^^^^^^^^^^^^^^^^^^^^^^
```
Found while working on https://github.com/rust-lang/rust/pull/79540. cc https://github.com/rust-lang/rust/pull/81645, which landed in 1.51.
Bump stabilization version for const int methods
These methods missed the beta cutoff. See #80962 for details.
`@rustbot` modify labels to +A-const-fn, +A-intrinsics
r? `@m-ou-se`
Make Vec::split_at_spare_mut public
This PR introduces a new method to the public API, under
`vec_split_at_spare` feature gate:
```rust
impl<T, A: Allocator> impl Vec<T, A> {
pub fn split_at_spare_mut(&mut self) -> (&mut [T], &mut [MaybeUninit<T>]);
}
```
The method returns 2 slices, one slice references the content of the vector,
and the other references the remaining spare capacity.
The method was previously implemented while adding `Vec::extend_from_within` in #79015,
and used to implement `Vec::spare_capacity_mut` (as the later is just a
subset of former one).
See also previous [discussion in `Vec::spare_capacity_mut` tracking issue](https://github.com/rust-lang/rust/issues/75017#issuecomment-770381335).
## Unresolved questions
- [ ] Should we consider changing the name? `split_at_spare_mut` doesn't seem like an intuitive name
- [ ] Should we deprecate `Vec::spare_capacity_mut`? Any usecase of `Vec::spare_capacity_mut` can be replaced with `Vec::split_at_spare_mut` (but not vise-versa)
r? `@KodrAus`
