Rollup of 9 pull requests #120309
Merged
Rollup of 9 pull requests #120309
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
It looks like none of these are actually needed.
Also add tests for min-system-llvm-version.
Signed-off-by: Ryan Levick <[email protected]>
Co-authored-by: David Wood <[email protected]>
… r=joshtriplett [style edition 2024] Combine all delimited exprs as last argument Closes rust-lang/style-team#149 If this is merged, the rustfmt option `overflow_delimited_expr` should be enabled by default in style edition 2024. [Rendered](https://github.com/pitaj/rust/blob/style-delimited-expressions/src/doc/style-guide/src/expressions.md#combinable-expressions) r? joshtriplett
…tmcm
Add `NonZero*::count_ones`
This PR adds the following APIs to the standard library:
```rust
impl NonZero* {
pub const fn count_ones(self) -> NonZeroU32;
}
```
This is potentially interesting, given that `count_ones` can't ever return 0.
r? libs-api
…wiser coverage: Never emit improperly-ordered coverage regions If we emit a coverage region that is improperly ordered (end < start), `llvm-cov` will fail with `coveragemap_error::malformed`, which is inconvenient for users and also very hard to debug. Ideally we would fix the root causes of these situations, but they tend to occur in very obscure edge-case scenarios (often involving nested macros), and we don't always have a good MCVE to work from. So it makes sense to also have a catch-all check that will prevent improperly-ordered regions from ever being emitted. --- This is mainly aimed at resolving rust-lang#119453. We don't have a specific way to reproduce it, which is why I haven't been able to add a test case in this PR. But based on the information provided in that issue, this change seems likely to avoid the error in `llvm-cov`. `````@rustbot````` label +A-code-coverage
…ochenkov,m-ou-se Add a new `wasm32-wasi-preview2` target This is the initial implementation of the MCP rust-lang/compiler-team#694 creating a new tier 3 target `wasm32-wasi-preview2`. That MCP has been seconded and will most likely be approved in a little over a week from now. For more information on the need for this target, please read the [MCP](rust-lang/compiler-team#694). There is one aspect of this PR that will become insta-stable once these changes reach a stable compiler: * A new `target_family` named `wasi` is introduced. This target family incorporates all wasi targets including `wasm32-wasi` and its derivative `wasm32-wasi-preview1-threads`. The difference between `target_family = wasi` and `target_os = wasi` will become much clearer when `wasm32-wasi` is renamed to `wasm32-wasi-preview1` and the `target_os` becomes `wasm32-wasi-preview1`. You can read about this target rename in [this MCP](rust-lang/compiler-team#695) which has also been seconded and will hopefully be officially approved soon. Additional technical details include: * Both `std::sys::wasi_preview2` and `std::os::wasi_preview2` have been created and mostly use `#[path]` annotations on their submodules to reach into the existing `wasi` (soon to be `wasi_preview1`) modules. Over time the differences between `wasi_preview1` and `wasi_preview2` will grow and most like all `#[path]` based module aliases will fall away. * Building `wasi-preview2` relies on a [`wasi-sdk`](https://github.com/WebAssembly/wasi-sdk) in the same way that `wasi-preview1` does (one must include a `wasi-root` path in the `Config.toml` pointing to sysroot included in the wasi-sdk). The target should build against [wasi-sdk v21](https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-21) without modifications. However, the wasi-sdk itself is growing [preview2 support](WebAssembly/wasi-sdk#370) so this might shift rapidly. We will be following along quickly to make sure that building the target remains possible as the wasi-sdk changes. * This requires a [patch to libc](https://github.com/rylev/rust-libc/tree/wasm32-wasi-preview2) that we'll need to land in conjunction with this change. Until that patch lands the target won't actually build.
coverage: Don't instrument `#[automatically_derived]` functions This PR makes the coverage instrumentor detect and skip functions that have [`#[automatically_derived]`](https://doc.rust-lang.org/reference/attributes/derive.html#the-automatically_derived-attribute) on their enclosing impl block. Most notably, this means that methods generated by built-in derives (e.g. `Clone`, `Debug`, `PartialEq`) are now ignored by coverage instrumentation, and won't appear as executed or not-executed in coverage reports. This is a noticeable change in user-visible behaviour, but overall I think it's a net improvement. For example, we've had a few user requests for this sort of change (e.g. rust-lang#105055, rust-lang#84605 (comment)), and I believe it's the behaviour that most users will expect/prefer by default. It's possible to imagine situations where users would want to instrument these derived implementations, but I think it's OK to treat that as an opportunity to consider adding more fine-grained option flags to control the details of coverage instrumentation, while leaving this new behaviour as the default. (Also note that while `-Cinstrument-coverage` is a stable feature, the exact details of coverage instrumentation are allowed to change. So we *can* make this change; the main question is whether we *should*.) Fixes rust-lang#105055.
Remove no-system-llvm We currently have a bunch of codegen tests that use no-system-llvm -- however, all of those tests also pass with system LLVM 16. I've opted to remove `no-system-llvm` entirely, as there's basically no valid use case for it anymore: * The only thing this option could have legitimately been used for (testing the target feature support that requires an LLVM patch) doesn't use it, and the need for this will go away with LLVM 18 anyway. * In cases where the test depends on optimizations/fixes from newer LLVM versions, `min-llvm-version` should be used instead. * In case it depends on optimization/fixes from newer LLVM versions that have been backported into our fork, `min-system-llvm-version` (with the major version larger than the one in our fork) should be used instead. r? `````@cuviper`````
privacy: Refactor top-level visiting in `TypePrivacyVisitor` Full hierarchical visiting (`nested_filter::All`) is not necessary, visiting all item-likes in isolation is enough. Tracking current item is not necessary, just keeping the current `mod` item is enough. `visit_generic_arg` should behave like its default version, including checking types of const arguments. Some comments, including FIXMEs, are also added. Noticed while reading code to review rust-lang#113671. r? ``@oli-obk``
Remove extra # from url in suggestion The suggestion added in rust-lang#119805 contains an unnecessary # hash sign.
…pdate, r=davidtwco Add mw to review rotation and add some owner assignments I've also added a `debuginfo` group and fixed the ownership assignment for the `incremental` group. I hope I got the syntax right. r? ``@davidtwco``
rustbot
added
A-meta
rustbot
added
T-style
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: cd6d8f2a04 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jan 24, 2024
Merged
|
Finished benchmarking commit (7ffc697): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 663.194s -> 664.789s (0.24%) |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 28, 2024
Revert outdated version of "Add the wasm32-wasi-preview2 target" An outdated version of rust-lang#119616 was merged in rollup rust-lang#120309. This reverts those changes to enable rust-lang#119616 to “retain the intended diff” after a rebase. `@rylev` has agreed that this would be the cleanest approach with respect to the history. Unblocks rust-lang#119616. r? `@petrochenkov` or compiler or libs
fmease
added a commit
to fmease/rust
that referenced
this pull request
Jan 29, 2024
Revert outdated version of "Add the wasm32-wasi-preview2 target" An outdated version of rust-lang#119616 was merged in rollup rust-lang#120309. This reverts those changes to enable rust-lang#119616 to “retain the intended diff” after a rebase. ``@rylev`` has agreed that this would be the cleanest approach with respect to the history. Unblocks rust-lang#119616. r? ``@petrochenkov`` or compiler or libs
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Jan 30, 2024
Revert outdated version of "Add the wasm32-wasi-preview2 target" An outdated version of rust-lang#119616 was merged in rollup rust-lang#120309. This reverts those changes to enable rust-lang#119616 to “retain the intended diff” after a rebase. ```@rylev``` has agreed that this would be the cleanest approach with respect to the history. Unblocks rust-lang#119616. r? ```@petrochenkov``` or compiler or libs
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 30, 2024
Rollup merge of rust-lang#120434 - fmease:revert-speeder, r=petrochenkov Revert outdated version of "Add the wasm32-wasi-preview2 target" An outdated version of rust-lang#119616 was merged in rollup rust-lang#120309. This reverts those changes to enable rust-lang#119616 to “retain the intended diff” after a rebase. ```@rylev``` has agreed that this would be the cleanest approach with respect to the history. Unblocks rust-lang#119616. r? ```@petrochenkov``` or compiler or libs
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:
NonZero*::count_ones#118326 (AddNonZero*::count_ones)wasm32-wasip2target #119616 (Add a newwasm32-wasi-preview2target)#[automatically_derived]functions #120185 (coverage: Don't instrument#[automatically_derived]functions)TypePrivacyVisitor#120284 (privacy: Refactor top-level visiting inTypePrivacyVisitor)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup