Slightly optimize hash map stable hashing
I was profiling some of the `rustc-perf` benchmarks locally and noticed that quite some time is spent inside the stable hash of hashmaps. I tried to use a `SmallVec` instead of a `Vec` there, which helped very slightly.
Then I tried to remove the sorting, which was a bottleneck, and replaced it with insertion into a binary heap. Locally, it yielded nice improvements in instruction counts and RSS in several benchmarks for incremental builds. The implementation could probably be much nicer and possibly extended to other stable hashes, but first I wanted to test the perf impact properly.
Can I ask someone to do a perf run? Thank you!
I think it's helpful to know what type was unused when looking at these
warnings. The type will likely determine whether the result *should* be
used, or whether it should just be ignored.
Including the type also matches the behavior of the `must_use` lint:
unused `SomeType` that must be used.
Rollup of 8 pull requests
Successful merges:
- #90081 (Make `intrinsics::write_bytes` const)
- #91643 (asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target)
- #91737 (Make certain panicky stdlib functions behave better under panic_immediate_abort)
- #91750 (rustdoc: Add regression test for Iterator as notable trait on &T)
- #91764 (Do not ICE when suggesting elided lifetimes on non-existent spans.)
- #91780 (Remove hir::Node::hir_id.)
- #91797 (Fix zero-sized reference to deallocated memory)
- #91806 (Make `Unique`s methods `const`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This commit adds autolabeling for the `T-rustdoc` label, for PRs that
modify rustdoc's source code, tests, or internal tooling.
This is possible now that rust-lang/triagebot#1321 has landed.
rustdoc: Add regression test for Iterator as notable trait on &T
Closes#78160
This regression test is different from the one in #91748, because while neither of these function should have Iterator marked as a notable trait, the reasons are different.
* In this PR, it returns `&T where T: Iterator`. The `mut` is what's missing.
* In #91748, it returns `&mut T`. The trait bounds are what's missing.
Make certain panicky stdlib functions behave better under panic_immediate_abort
The stdlib has a `panic_immediate_abort` feature that turns panics into immediate aborts, without any formatting/display logic. This feature was [introduced](https://github.com/rust-lang/rust/pull/55011) primarily for codesize-constrained situations.
Unfortunately, this win doesn't quite propagate to `Result::expect()` and `Result::unwrap()`, while the formatting machinery is reduced, `expect()` and `unwrap()` both call `unwrap_failed("msg", &err)` which has a signature of `fn unwrap_failed(msg: &str, error: &dyn fmt::Debug)` and is `#[inline(never)]`. This means that `unwrap_failed` will unconditionally construct a `dyn Debug` trait object even though the object is never used in the function.
Constructing a trait object (even if you never call a method on it!) forces rust to include the vtable and any dependencies. This means that in `panic_immediate_abort` mode, calling expect/unwrap on a Result will pull in a whole bunch of formatting code for the error type even if it's completely unused.
This PR swaps out the function with one that won't require a trait object such that it won't force the inclusion of vtables in the code. It also gates off `#[inline(never)]` in a bunch of other places where allowing the inlining of an abort may be useful (this kind of thing is already done elsewhere in the stdlib).
I don't know how to write a test for this; we don't really seem to have any tests for `panic_immediate_abort` anyway so perhaps it's fine as is.
asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target
This supersedes https://github.com/rust-lang/rust/pull/88879.
cc `@Skirmisher`
r? `@joshtriplett`
On Windows, `x.py dist` command panics without proper error message if 'WIX' environment variable is not set. This patch changes `Option::unwrap()` to `Option::expect()`.
Tweak assoc type obligation spans
* Point at RHS of associated type in obligation span
* Point at `impl` assoc type on projection error
* Reduce verbosity of recursive obligations
* Point at source of binding lifetime obligation
* Tweak "required bound" note
* Tweak "expected... found opaque (return) type" labels
* Point at set type in impl assoc type WF errors
r? `@oli-obk`
This is a(n uncontroversial) subset of #85799.
Minor improvements to `future::join!`'s implementation
This is a follow-up from #91645, regarding [some remarks I made](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/join!/near/264293660).
Mainly:
- it hides the recursive munching through a private `macro`, to avoid leaking such details (a corollary is getting rid of the need to use ``@`` to disambiguate);
- it uses a `match` binding, _outside_ the `async move` block, to better match the semantics from function-like syntax;
- it pre-pins the future before calling into `poll_fn`, since `poll_fn`, alone, cannot guarantee that its capture does not move (to clarify: I believe the previous code was sound, thanks to the outer layer of `async`. But I find it clearer / more robust to refactorings this way 🙂).
- it uses `@ibraheemdev's` very neat `.ready()?`;
- it renames `Took` to `Taken` for consistency with `Done` (tiny nit 😄).
~~TODO~~Done:
- [x] Add unit tests to enforce the function-like `:value` semantics are respected.
r? `@nrc`
Add spin_loop hint for RISC-V architecture
This commit uses the PAUSE instruction (https://github.com/rust-lang/stdarch/pull/1262) to implement RISC-V spin loop, and updates `stdarch` submodule to use the merged PAUSE instruction.
Point at capture points for non-`'static` reference crossing a `yield` point
```
error[E0759]: `self` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement
--> $DIR/issue-72312.rs:10:24
|
LL | pub async fn start(&self) {
| ^^^^^ this data with an anonymous lifetime `'_`...
...
LL | require_static(async move {
| -------------- ...is required to live as long as `'static` here...
LL | &self;
| ----- ...and is captured here
|
note: `'static` lifetime requirement introduced by this trait bound
--> $DIR/issue-72312.rs:2:22
|
LL | fn require_static<T: 'static>(val: T) -> T {
| ^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0759`.
```
Fix#72312.
Suggest using a temporary variable to fix borrowck errors
Fixes#77834.
In Rust, nesting method calls with both require `&mut` access to `self`
produces a borrow-check error:
error[E0499]: cannot borrow `*self` as mutable more than once at a time
--> src/lib.rs:7:14
|
7 | self.foo(self.bar());
| ---------^^^^^^^^^^-
| | | |
| | | second mutable borrow occurs here
| | first borrow later used by call
| first mutable borrow occurs here
That's because Rust has a left-to-right evaluation order, and the method
receiver is passed first. Thus, the argument to the method cannot then
mutate `self`.
There's an easy solution to this error: just extract a local variable
for the inner argument:
let tmp = self.bar();
self.foo(tmp);
However, the error doesn't give any suggestion of how to solve the
problem. As a result, new users may assume that it's impossible to
express their code correctly and get stuck.
This commit adds a (non-structured) suggestion to extract a local
variable for the inner argument to solve the error. The suggestion uses
heuristics that eliminate most false positives, though there are a few
false negatives (cases where the suggestion should be emitted but is
not). Those other cases can be implemented in a future change.
Rollup of 7 pull requests
Successful merges:
- #91617 (Improve the readability of `List<T>`.)
- #91640 (Simplify collection of in-band lifetimes)
- #91682 (rustdoc: Show type layout for type aliases)
- #91711 (Improve `std::iter::zip` example)
- #91717 (Add deprecation warning for --passes)
- #91718 (give more help in the unaligned_references lint)
- #91782 (Correct since attribute for `is_symlink` feature)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: Show type layout for type aliases
Fixes#91265.
At first, you might think, "Why not just click through to the aliased
type?" But, if a type alias instantiates all of the generic parameters
of the aliased type, then it can show layout info even though the
aliased type cannot (because we can't compute layout for generic types).
So, I think it's useful to show layout info for type aliases.
This is a followup of 78d4b453ad2e19d44011b26fc55c949bff5dba3d
(originally part of #83501).
Improve the readability of `List<T>`.
This commit does the following.
- Expands on some of the things already mentioned in comments.
- Describes the uniqueness assumption, which is critical but wasn't
mentioned at all.
- Rewrites `empty()` into a clearer form, as provided by Daniel
Henry-Mantilla on Zulip.
- Reorders things slightly so that more important things
are higher up, and incidental things are lower down, which makes
reading the code easier.
r? ````@lcnr````
