Rollup of 9 pull requests #118767
Closed
Rollup of 9 pull requests #118767
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 is desired for rust-lang#118702.
as they unnecessarily clutter the diagnostic output and make the experience of adding a new target to the compiler more painful than it should be. target_os and target_arch are still being tested in the well-known-values.rs test, but in one place.
… MIR There are cases where coverage instrumentation wants to show a span for some syntax element, but there is no MIR node that naturally carries that span, so the instrumentor can't see it. MIR building can now use this new kind of coverage statement to deliberately include those spans in MIR, attached to a dummy statement that has no other effect.
This replaces the previous workaround, which was to inject a dummy `Assign` statement.
When MIR is built for an if-not expression, the `!` part of the condition doesn't correspond to any MIR statement, so coverage instrumentation normally can't see it. We can fix that by deliberately injecting a dummy statement whose sole purpose is to associate that span with its enclosing block.
This should make it easier to investigate unwrap failures in bug reports.
LLVM commit llvm/llvm-project@e817966 renamed the `unaligned-scalar-mem` target feature to `fast-unaligned-access`.
according to a poll of gay people in my phone, purple is the most popular color to use for highlighting | color | percentage | | ---------- | ---------- | | bold white | 6% | | blue | 14% | | cyan | 26% | | purple | 37% | | magenta | 17% | unfortunately, purple is not supported by 16-color terminals, which rustc apparently wants to support for some reason. until we require support for full 256-color terms (e.g. by doing the same feature detection as we currently do for urls), we can't use it. instead, i have collapsed the purple votes into magenta on the theory that they're close, and also because magenta is pretty.
coverage: Use `SpanMarker` to improve coverage spans for `if !` expressions Coverage instrumentation works by extracting source code spans from MIR. However, some kinds of syntax are effectively erased during MIR building, so their spans don't necessarily exist anywhere in MIR, making them invisible to the coverage instrumentor (unless we resort to various heuristics and hacks to recover them). This PR introduces `CoverageKind::SpanMarker`, which is a new variant of `StatementKind::Coverage`. Its sole purpose is to represent spans that would otherwise not appear in MIR, so that the coverage instrumentor can extract them. When coverage is enabled, the MIR builder can insert these dummy statements as needed, to improve the accuracy of spans used by coverage mappings. Fixes rust-lang#115468. --- `@rustbot` label +A-code-coverage
…ted-tests, r=jackh726 Add tests related to normalization in implied bounds Getting `@aliemjay's` tests from rust-lang#109763, so we can better track what's going on in every different example. r? `@jackh726`
update target feature following LLVM API change LLVM commit llvm/llvm-project@e817966 renamed* the `unaligned-scalar-mem` target feature to `fast-unaligned-access`. (*) technically the commit folded two previous features into one, but there are no references to the other one in rust.
coverage: Simplify the heuristic for ignoring `async fn` return spans The code for extracting coverage spans from MIR has a special heuristic for dealing with `async fn`, so that the function's closing brace does not have a confusing double count. The code implementing that heuristic is currently mixed in with the code for flushing remaining spans after the main refinement loop, making the refinement code harder to understand. We can solve that by hoisting the heuristic to an earlier stage, after the spans have been extracted and sorted but before they have been processed by the refinement loop. The coverage tests verify that the heuristic is still effective, so coverage mappings/reports for `async fn` have not changed. --- This PR also has the side-effect of fixing the `None some_prev` panic that started appearing after rust-lang#118525. The old code assumed that `prev` would always be present after the refinement loop. That was only true if the list of collected spans was non-empty, but prior to rust-lang#118525 that didn't seem to come up in practice. After that change, the list of collected spans could be empty in some specific circumstances, leading to panics. The new code uses an `if let` to inspect `prev`, which correctly does nothing if there is no span present.
…own, r=nnethercote Strengthen well known check-cfg names and values test rust-lang#118494 is changing the implementation of how we expect well known check-cfg names and values, but we currently don't have a test that checks every well known only some of them. This PR therefore strengthen our well known names/values test to include all of the configs to at least avoid unintended regressions and validate new entry. *this PR also contains some drive-by consolidation of unexpected `target_os`, `target_arch` into a single file* r? `@nnethercote` (maybe? feel free to re-assign)
…estsa, r=Nilstrieb Extend tidy alphabetical checking to `tests/`. This is desired for rust-lang#118702. r? `@Nilstrieb`
use bold magenta instead of bold white for highlighting according to a poll of gay people in my phone, purple is the most popular color to use for highlighting | color | percentage | | ---------- | ---------- | | bold white | 6% | | blue | 14% | | cyan | 26% | | purple | 37% | | magenta | 17% | unfortunately, purple is not supported by 16-color terminals, which rustc apparently wants to support for some reason. until we require support for full 256-color terms (e.g. by doing the same feature detection as we currently do for urls), we can't use it. instead, i have collapsed the purple votes into magenta on the theory that they're close, and also because magenta is pretty. before:  after:  other colors for comparison: blue:  cyan:  purple:  magenta without bolding:  r? `@estebank`
Some more minor `async gen`-related nits Tiny tweaks found after `async gen` pr landed r? eholk
…or, r=eholk Make async generators fused by default I actually changed my mind about this since the implementation PR landed. I think it's beneficial for `async gen` blocks to be "fused" by default -- i.e., for them to repeatedly return `Poll::Ready(None)` -- rather than panic. We have [`FusedStream`](https://docs.rs/futures/latest/futures/stream/trait.FusedStream.html) in futures-rs to represent streams with this capability already anyways. r? eholk cc `@rust-lang/wg-async,` would like to know if anyone else has opinions about this.
rustbot
added
A-testsuite
rustbot
added
T-bootstrap
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
@bors r- |
bors
added
S-waiting-on-author
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:
SpanMarkerto improve coverage spans forif !expressions #118198 (coverage: UseSpanMarkerto improve coverage spans forif !expressions)async fnreturn spans #118666 (coverage: Simplify the heuristic for ignoringasync fnreturn spans)tests/. #118737 (Extend tidy alphabetical checking totests/.)async gen-related nits #118762 (Some more minorasync gen-related nits)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup