Rollup of 10 pull requests #89089
Merged
Rollup of 10 pull requests #89089
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
This PR adds a suggestion to replace an inexisting field for an
unmentioned field. Given the following code:
```rust
enum Foo {
Bar { alpha: u8, bravo: u8, charlie: u8 },
}
fn foo(foo: Foo) {
match foo {
Foo::Bar {
alpha,
beta, // `bravo` miswritten as `beta` here.
charlie,
} => todo!(),
}
}
```
the compiler now emits the error messages below.
```text
error[E0026]: variant `Foo::Bar` does not have a field named `beta`
--> src/lib.rs:9:13
|
9 | beta, // `bravo` miswritten as `beta` here.
| ^^^^
| |
| variant `Foo::Bar` does not have this field
| help: `Foo::Bar` has a field named `bravo`: `bravo`
```
Note that this suggestion is available iff the number of inexisting
fields and unmentioned fields are both 1.
When a macro is used in the trailing expression position of a block
(e.g. `fn foo() { my_macro!() }`), we currently parse it as an
expression, rather than a statement. As a result, we ended up
using the `NodeId` of the containing statement as our `lint_node_id`,
even though we don't normally do this for macro calls.
If such a macro expands to an expression with a `#[cfg]` attribute,
then the trailing statement can get removed entirely. This lead to
an ICE, since we were usng the `NodeId` of the expression to emit
a lint.
Ths commit makes us skip updating `lint_node_id` when handling
a macro in trailing expression position. This will cause us to
lint at the closest parent of the macro call.
Previously "trait bounds other than `Sized` on const fn parameters are unstable" error was used for both trait bounds (<T: Trait>) and trait objects (dyn Trait). This was pretty confusing. This patch adds a separeta error for trait objects: "trait objects in const fn are unstable". The error for trait bounds is otherwise intact.
> add intra doc links > add a usage example for the os::windows module
…rapped in parentheses
…d-for-unmentioned-field, r=estebank Suggest replacing an inexisting field for an unmentioned field Fix rust-lang#87938 This PR adds a suggestion to replace an inexisting field for an unmentioned field. Given the following code: ```rust enum Foo { Bar { alpha: u8, bravo: u8, charlie: u8 }, } fn foo(foo: Foo) { match foo { Foo::Bar { alpha, beta, // `bravo` miswritten as `beta` here. charlie, } => todo!(), } } ``` the compiler now emits the error messages below. ```text error[E0026]: variant `Foo::Bar` does not have a field named `beta` --> src/lib.rs:9:13 | 9 | beta, // `bravo` miswritten as `beta` here. | ^^^^ | | | variant `Foo::Bar` does not have this field | help: `Foo::Bar` has a field named `bravo`: `bravo` ``` Note that this suggestion is available iff the number of inexisting fields and unmentioned fields are both 1.
… r=nagisa Allow simd_shuffle to accept vectors of any length cc ``@rust-lang/project-portable-simd`` ``@workingjubilee``
…trochenkov Check for shadowing issues involving block labels
…trochenkov
Fix linting when trailing macro expands to a trailing semi
When a macro is used in the trailing expression position of a block
(e.g. `fn foo() { my_macro!() }`), we currently parse it as an
expression, rather than a statement. As a result, we ended up
using the `NodeId` of the containing statement as our `lint_node_id`,
even though we don't normally do this for macro calls.
If such a macro expands to an expression with a `#[cfg]` attribute,
then the trailing statement can get removed entirely. This lead to
an ICE, since we were usng the `NodeId` of the expression to emit
a lint.
Ths commit makes us skip updating `lint_node_id` when handling
a macro in trailing expression position. This will cause us to
lint at the closest parent of the macro call.
…=kennytm fix potential race in AtomicU64 time monotonizer The AtomicU64-based monotonizer introduced in rust-lang#83093 is incorrect because several threads could try to update the value concurrently and a thread which doesn't have the newest value among all the updates could win. That bug probably has little real world impact since it doesn't make observed time worse than hardware clocks. The worst case would probably be a thread which has a clock that is behind by several cycles observing several inconsistent fixups, which should be similar to observing the unfiltered backslide in the first place. New benchmarks, they don't look as good as the original PR but still an improvement compared to the mutex. I don't know why the contended mutex case is faster now than in the previous benchmarks. ``` actually_monotonic() == true: test time::tests::instant_contention_01_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 45 ns/iter (+/- 0) test time::tests::instant_contention_04_threads ... bench: 45 ns/iter (+/- 0) test time::tests::instant_contention_08_threads ... bench: 45 ns/iter (+/- 0) test time::tests::instant_contention_16_threads ... bench: 46 ns/iter (+/- 0) atomic u64: test time::tests::instant_contention_01_threads ... bench: 66 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 287 ns/iter (+/- 14) test time::tests::instant_contention_04_threads ... bench: 296 ns/iter (+/- 43) test time::tests::instant_contention_08_threads ... bench: 604 ns/iter (+/- 163) test time::tests::instant_contention_16_threads ... bench: 1,147 ns/iter (+/- 29) mutex: test time::tests::instant_contention_01_threads ... bench: 78 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 652 ns/iter (+/- 275) test time::tests::instant_contention_04_threads ... bench: 900 ns/iter (+/- 32) test time::tests::instant_contention_08_threads ... bench: 1,927 ns/iter (+/- 62) test time::tests::instant_contention_16_threads ... bench: 3,748 ns/iter (+/- 146) ```
…_trait_in_const_fn, r=estebank Add a separate error for `dyn Trait` in `const fn` Previously "trait bounds other than `Sized` on const fn parameters are unstable" error was used for both trait bounds (`<T: Trait>`) and trait objects (`dyn Trait`). This was pretty confusing. This PR adds a separate error for trait objects: "trait objects in const fn are unstable". The error for trait bounds is otherwise intact. This is follow up to rust-lang#88907 r? ``@estebank`` ``@rustbot`` label: +A-diagnostics
Add intra-doc links and small changes to `std::os` to be more consistent I believe that a few items in `std::os` should be linked. I've also added a basic example in `std::os::windows`.
…rivate, r=Mark-Simulacrum refactor: VecDeques IntoIter fields to private Made the fields of VecDeque's IntoIter private by creating a IntoIter::from(...) function to create a new instance of IntoIter and migrating usage to use IntoIter::from(...).
…ens, r=wesleywiser Suggest better place to add call parentheses for method expressions wrapped in parentheses I wanted to improve the suggestion a bit to both remove the wrapping parentheses **and** add call parentheses by both calling `suggest_method_call` and using `multipart_suggestion`. But I very quickly ran into a problem where multiple overlapping machine applicable suggestions cannot be properly applied together. So I applied the suggestion from the issue and only added the call parentheses directly after the expression. Fixes: rust-lang#89044
Fix a typo Removed extra spaces in front of commas
|
@bors r+ p=10 rollup=never |
|
📌 Commit 4877ad3 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (08a0307): 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:
dyn Traitinconst fn#89021 (Add a separate error fordyn Traitinconst fn)std::osto be more consistent #89051 (Add intra-doc links and small changes tostd::osto be more consistent)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup