Rollup of 10 pull requests #120303
Closed
Rollup of 10 pull requests #120303
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
…ed -Z unstable-options` to shorten symbol names by replacing them with a digest. Enrich test cases
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
Add the unstable option to reduce the binary size of dynamic library… # Motivation The average length of symbol names in the rust standard library is about 100 bytes, while the average length of symbol names in the C++ standard library is about 65 bytes. In some embedded environments where dynamic library are widely used, rust dynamic library symbol name space hash become one of the key bottlenecks of application, Especially when the existing C/C++ module is reconstructed into the rust module. The unstable option `-Z symbol_mangling_version=hashed` is added to solve the bottleneck caused by too long dynamic library symbol names. ## Test data The following is a set of test data on the ubuntu 18.04 LTS environment. With this plug-in, the space saving rate of dynamic libraries can reach about 20%. The test object is the standard library of rust (built based on Xargo), tokio crate, and hyper crate. The contents of the Cargo.toml file in the construction project of the three dynamic libraries are as follows: ```txt # Cargo.toml [profile.release] panic = "abort" opt-leve="z" codegen-units=1 strip=true debug=true ``` The built dynamic library also removes the `.rustc` segments that are not needed at run time and then compares the size. The detailed data is as follows: 1. libstd.so > | symbol_mangling_version | size | saving rate | > | --- | --- | --- | > | legacy | 804896 || > | hashed | 608288 | 0.244 | > | v0 | 858144 || > | hashed | 608288 | 0.291 | 2. libhyper.so > | symbol_mangling_version(libhyper.so) | symbol_mangling_version(libstd.so) | size | saving rate | > | --- | --- | --- | --- | > | legacy | legacy | 866312 || > | hashed | legacy | 645128 |0.255| > | legacy | hashed | 854024 || > | hashed | hashed | 632840 |0.259|
…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-libs
|
@bors r+ rollup=never p=10 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 24, 2024
Rollup of 10 pull requests Successful merges: - rust-lang#114764 ([style edition 2024] Combine all delimited exprs as last argument) - rust-lang#118326 (Add `NonZero*::count_ones`) - rust-lang#118636 (Add the unstable option to reduce the binary size of dynamic library…) - rust-lang#119460 (coverage: Never emit improperly-ordered coverage regions) - rust-lang#119616 (Add a new `wasm32-wasi-preview2` target) - rust-lang#120185 (coverage: Don't instrument `#[automatically_derived]` functions) - rust-lang#120265 (Remove no-system-llvm) - rust-lang#120284 (privacy: Refactor top-level visiting in `TypePrivacyVisitor`) - rust-lang#120285 (Remove extra # from url in suggestion) - rust-lang#120299 (Add mw to review rotation and add some owner assignments) Failed merges: - rust-lang#120124 (Split assembly tests for ELF and MachO) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
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)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup