-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 5 pull requests #133723
Rollup of 5 pull requests #133723
Conversation
This context is stored in `CodegenCx`, which makes it per-CGU rather than per-crate. A single crate can have multiple CGUs.
There is unlikely to be any practical difference between a counter limit of 2^32 and a counter limit of (2^32 - 256).
This is currently handled automatically by the fact that codegen doesn't visit coverage statements in unused functions, but that will no longer be the case when unused IDs are identified by a separate query instead.
Mark `slice::copy_from_slice` unstably const Tracking issue rust-lang#131415 I used `const_eval_select` for runtime and const panic functions because const formatting isn't available yet.
Stabilize unsigned and float variants of `num_midpoint` feature This PR proposes that we stabilize the unsigned variants of the [`num_midpoint`](rust-lang#110840 (comment)) feature as well as the floats variants, since they are not subject to any unresolved questions, which is equivalent to doing `(a + b) / 2` (and `(a + b) >> 1`) in a sufficiently large number. The stabilized API surface would be: ```rust /// Calculates the middle point of `self` and `rhs`. /// /// `midpoint(a, b)` is `(a + b) / 2` as if it were performed in a sufficiently-large unsigned integral type. /// This implies that the result is always rounded towards negative infinity and that no overflow will ever occur. impl u{8,16,32,64,128,size} { pub const fn midpoint(self, rhs: Self) -> Self; } impl NonZeroU{8,16,32,64,size} { pub const fn midpoint(self, rhs: Self) -> Self; } impl f{32,64} { pub const fn midpoint(self, rhs: Self) -> Self; } ``` The signed variants `u{8,16,32,64,128,size}` would remain gated, until a decision is made about the rounding mode, in other words that the [unresolved questions](rust-lang#110840 (comment)) are resolved. cc `@rust-lang/libs-api` cc `@scottmcm` r? libs-api
coverage: Use a query to identify which counter/expression IDs are used Given that we already have a query to identify the highest-numbered counter ID in a MIR body, we can extend that query to also build bitsets of used counter/expression IDs. That lets us avoid some messy coverage bookkeeping during the main MIR traversal for codegen. This does mean that we fail to treat some IDs as used in certain MIR-inlining scenarios, but I think that's fine, because it means that the results will be consistent across all instantiations of a function. --- There's some more cleanup I want to do in the function coverage collector, since it isn't really collecting anything any more, but I'll leave that for future work.
add isatty doc alias for `is_terminal` (first Rust contribution!) This adds `isatty` as a doc alias for [`std::io::IsTerminal::is_terminal`](https://doc.rust-lang.org/stable/std/io/trait.IsTerminal.html#tymethod.is_terminal). I think this change does meet the [doc alias policy](https://std-dev-guide.rust-lang.org/policy/doc-alias.html). This would be especially useful because searching "rust isatty" gets you the `isatty` crate which is deprecated in favor of `atty`. `atty` is unmaintained and you might get to `is-terminal`, which will finally tell you that the function you're looking for has been in `std` all along. The Windows implementation of `is_terminal()` doesn't use `isatty`, but that hasn't been a problem for the analogous cases of `create_dir()`'s alias `mkdir` or `remove_dir()`/`rmdir`.
…=jieyouxu rust_analyzer_settings: force use of 'nightly' toolchain The cranelift folder contains a rust-toolchain file. That means when RA opens `compiler/rustc_codegen_cranelift/Cargo.toml`, it will try to use that toolchain or fail. (Maybe that toolchain gets auto-installed for others? On my system, it just fails, but I also run vscodium in a sandbox.) However, it shouldn't be necessary to use more than one toolchain for the rustc workspace. So we can set the `RUSTUP_TOOLCHAIN` variable on the server side to force the same toolchain to be used everywhere. Suggested by `@ChayimFriedman2` in rust-lang/rust-analyzer#18585.
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: a522d78598 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (caa8172): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 1.8%, secondary 0.8%)This 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (primary 0.1%, secondary 0.1%)This 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.
Bootstrap: 768.623s -> 768.592s (-0.00%) |
Successful merges:
slice::copy_from_slice
unstably const #131416 (Markslice::copy_from_slice
unstably const)num_midpoint
feature #131784 (Stabilize unsigned and float variants ofnum_midpoint
feature)is_terminal
#133711 (add isatty doc alias foris_terminal
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup