More newsched fixes #8282
Closed
More newsched fixes #8282
Conversation
This file contains hidden or 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
|
@toddaaro 5e180bc is important |
Also fix some incorrect comments and variable names.
Otherwise interferes with the existing runtime
rustc needs *even more* megabytes when run without optimizations
Every time run_sched_once performs a 'scheduling action' it needs to guarantee that it runs at least one more time, so enqueue another run_sched_once callback. The primary reason it needs to do this is because not all async callbacks are guaranteed to run, it's only guaranteed that *a* callback will run after enqueing one - some may get dropped. At the moment this means we wastefully create lots of callbacks to ensure that there will *definitely* be a callback queued up to continue running the scheduler. The logic really needs to be tightened up here.
This is no longer testable once newsched is turned on
Not compatible with newsched
|
Even with this there is still a bug in the scheduler where it exits without emptying the message queue. Can't get make check to pass yet. |
bors
added a commit
that referenced
this pull request
Aug 5, 2013
|
I have an additional follow-up that fixes the remaining problem with dropped messages. |
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Feb 10, 2022
This commit changes the behavior of `single_match` lint.
After that, we won't lint non-exhaustive matches like this:
```rust
match Some(v) {
Some(a) => println!("${:?}", a),
None => {},
}
```
The rationale is that, because the type of `a` could be changed, so the
user can get non-exhaustive match after applying the suggested lint (see
rust-lang/rust-clippy#8282 (comment)
for context).
We also will lint `match` constructions with tuples. When we see the
tuples on the both arms, we will check them both at the same time, and
if they form exhaustive match, we could display the warning.
Closes rust-lang#8282
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Feb 10, 2022
single_match: Don't lint non-exhaustive matches; support tuples `single_match` lint: * Don't lint exhaustive enum patterns without a wild. Rationale: The definition of the enum could be changed, so the user can get non-exhaustive match after applying the suggested lint (see rust-lang/rust-clippy#8282 (comment) for context). * Lint `match` constructions with tuples (as suggested at rust-lang/rust-clippy#8282 (comment)) Closes rust-lang#8282 --- changelog: [`single_match`]: Don't lint exhaustive enum patterns without a wild. changelog: [`single_match`]: Lint `match` constructions with tuples
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.
No description provided.