Skip to content
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

Merged
merged 14 commits into from
Dec 2, 2024
Merged

Rollup of 5 pull requests #133723

merged 14 commits into from
Dec 2, 2024

Conversation

jhpratt
Copy link
Member

@jhpratt jhpratt commented Dec 2, 2024

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Zalathar and others added 14 commits November 30, 2024 00:54
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.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Dec 2, 2024
@jhpratt
Copy link
Member Author

jhpratt commented Dec 2, 2024

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Dec 2, 2024

📌 Commit 76183a5 has been approved by jhpratt

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 2, 2024
@bors
Copy link
Contributor

bors commented Dec 2, 2024

⌛ Testing commit 76183a5 with merge caa8172...

@bors
Copy link
Contributor

bors commented Dec 2, 2024

☀️ Test successful - checks-actions
Approved by: jhpratt
Pushing caa8172 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 2, 2024
@bors bors merged commit caa8172 into rust-lang:master Dec 2, 2024
7 checks passed
@rustbot rustbot added this to the 1.85.0 milestone Dec 2, 2024
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#131416 Mark slice::copy_from_slice unstably const 31144e8fff5c56f263b665f12954fe2f0a6e2283 (link)
#131784 Stabilize unsigned and float variants of num_midpoint fea… ffa9ca652f1e8ba99c5ae553a39f2a6d443814cc (link)
#133446 coverage: Use a query to identify which counter/expression … 2abc186a61890e9c20d5bc3379455a0228cf2b31 (link)
#133711 add isatty doc alias for is_terminal 550df3f297f6da39bca7b7e07c2594d3b3bc3ee8 (link)
#133712 rust_analyzer_settings: force use of 'nightly' toolchain 2be87303da2cbcb77f3eeed830b4842dfe8b3548 (link)

previous master: a522d78598

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (caa8172): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This 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.

mean range count
Regressions ❌
(primary)
1.8% [1.8%, 1.8%] 1
Regressions ❌
(secondary)
3.8% [3.8%, 3.8%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.2% [-2.2%, -2.2%] 1
All ❌✅ (primary) 1.8% [1.8%, 1.8%] 1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (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.

mean range count
Regressions ❌
(primary)
0.1% [0.1%, 0.1%] 4
Regressions ❌
(secondary)
0.1% [0.0%, 0.1%] 35
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.1% [0.1%, 0.1%] 4

Bootstrap: 768.623s -> 768.592s (-0.00%)
Artifact size: 332.16 MiB -> 332.14 MiB (-0.01%)

@jhpratt jhpratt deleted the rollup-pyfespf branch December 2, 2024 22:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants