Rollup of 7 pull requests #92482
Merged
Rollup of 7 pull requests #92482
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The existing documentation does not spell out whether `ThreadId`s are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly, as it's a strong guarantee. Examining the way `ThreadId`s are created also made me realise that the `as_u64` method on `ThreadId` could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to `ThreadId`). I therefore think it's worth being even clearer that there's no relationship between the two.
Fixes rust-lang#73026 See also: rust-lang#64467, rust-lang#89468 The issue stems from a `FatalError` being silently raised in `panictry_buffer`. Normally this is not a problem, because `panictry_buffer` emits the causes of the error, but they are not themselves fatal, so they get filtered out by the silent emitter. To fix this, we use a parser entrypoint which doesn't use `panictry_buffer`, and we handle the error ourselves.
Rustbuild already depends on once_cell which in the future can be replaced with std::lazy::Lazy.
The task of the macro is simple enough that a decl macro is almost ten times shorter than the original proc macro. The proc macro is 159 lines while the decl macro is just 18 lines. This reduces the amount of dependencies of rustbuild from 45 to 37. It also slight reduces compilation time from 47s to 44s for debug builds.
This slightly improves compilation time by reducing linking time (saving about a 1/10 of the the total compilation time after changing rustbuild) and slightly reduces disk usage (from 16MB for the rustc wrapper to 4MB).
Clarify the guarantees that ThreadId does and doesn't make. The existing documentation does not spell out whether `ThreadId`s are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly, as it's a strong guarantee. Examining the way `ThreadId`s are created also made me realise that the `as_u64` method on `ThreadId` could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to `ThreadId`). I therefore think it's worth being even clearer that there's no relationship between the two.
…ound, r=dtolnay
Remove unnecessary bounds for some Hash{Map,Set} methods
This PR moves `HashMap::{into_keys,into_values,retain}` and `HashSet::retain` from `impl` blocks with `K: Eq + Hash, S: BuildHasher` into the blocks without them. It doesn't seem to me there is any reason these methods need to be bounded by that. This change brings `HashMap::{into_keys,into_values}` on par with `HashMap::{keys,values,values_mut}` which are not bounded either.
…mulacrum Reduce compile time of rustbuild Best reviewed commit by commit. The `ignore` crate and it's dependencies are probably responsible for the majority of the compile time after this PR. cc `@jyn514` as you got a couple of open rustbuild PR.
…r=jsha Add test for where clause order I didn't use ``@snapshot`` because of the ` ` characters, it's much simpler doing it through rustdoc-gui testsuite. r? `@camelid`
…ark-Simulacrum Enforce formatting for rustc_codegen_cranelift
…, r=joshtriplett Remove pronunciation guide from Vec<T> I performed an extremely scientific poll on twitter, and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315
Emit an error for `--cfg=)` Fixes rust-lang#73026 See also: rust-lang#64467, rust-lang#89468 The issue stems from a `FatalError` being silently raised in `panictry_buffer`. Normally this is not a problem, because `panictry_buffer` emits the causes of the error, but they are not themselves fatal, so they get filtered out by the silent emitter. To fix this, we use a parser entrypoint which doesn't use `panictry_buffer`, and we handle the error ourselves.
rustbot
added
T-compiler
|
@bors r+ rollup=never p=7 |
|
📌 Commit 2004a51 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced Jan 2, 2022
|
Finished benchmarking commit (7b13c62): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
--cfg=)#92468 (Emit an error for--cfg=))Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup