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 #95745

Merged
merged 13 commits into from
Apr 7, 2022
Merged

Rollup of 5 pull requests #95745

merged 13 commits into from
Apr 7, 2022

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

m-ou-se and others added 13 commits March 21, 2022 22:57
libc::prctl and the prctl definitions in glibc, musl, and the kernel
headers are C variadic functions. Therefore, all the arguments (except
for the first) are untyped. It is only the Linux man page which says
that prctl takes 4 unsigned long arguments. I have no idea why it says
this.

In any case, the upshot is that we don't need to cast the pointer to an
integer and confuse Miri.
The current terse output gives 112 chars per line, which causes
wraparound for people using 100 char wide terminals, which is very
common.

This commit changes it to be exactly 100 wide, which makes the output
look much nicer.
…uviper

Don't cast thread name to an integer for prctl

`libc::prctl` and the `prctl` definitions in glibc, musl, and the kernel headers are C variadic functions. Therefore, all the arguments (except for the first) are untyped. It is only the Linux man page which says that `prctl` takes 4 `unsigned long` arguments. I have no idea why it says this.

In any case, the upshot is that we don't need to cast the pointer to an integer and confuse Miri.

But in light of this... what are we doing with those three `0`s? We're passing 3 `i32`s to `prctl`, which doesn't fill me with confidence. The man page says `unsigned long` and all the constants in the linux kernel are macros for expressions of the form `1UL << N`. I'm mostly commenting on this because looks a whole lot like some UB that was found in SQLite a few years ago: <https://youtu.be/LbzbHWdLAI0?t=1925> that was related to accidentally passing a 32-bit value from a literal `0` instead of a pointer-sized value. This happens to work on x86 due to the size of pointers and happens to work on x86_64 due to the calling convention. But also, there is no good reason for an implementation to be looking at those arguments. Some other calls to `prctl` require that other arguments be zeroed, but not `PR_SET_NAME`... so why are we even passing them?

I would prefer to end such questions by either passing 3 `libc::c_ulong`, or not passing those at all, but I'm not sure which is better.
…ut, r=Dylan-DPC

Improve terse test output.

The current terse output gives 112 chars per line, which causes
wraparound for people using 100 char wide terminals, which is very
common.

This commit changes it to be exactly 100 wide, which makes the output
look much nicer.
…r, r=compiler-errors

Revert "Mark Location::caller() as #[inline]"

This reverts rust-lang#95619. As noted in rust-lang#95619 (comment) this seems to break several tests with cg_clif.
…span, r=jsha

Switch item-info from div to span

Following discussion in rust-lang#95684.

cc `@jsha`
r? `@notriddle`
@rustbot rustbot added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Apr 6, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Apr 7, 2022

📌 Commit fe6d69f has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Apr 7, 2022
@bors
Copy link
Contributor

bors commented Apr 7, 2022

⌛ Testing commit fe6d69f with merge 2310da4...

@bors
Copy link
Contributor

bors commented Apr 7, 2022

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 2310da4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 7, 2022
@bors bors merged commit 2310da4 into rust-lang:master Apr 7, 2022
@rustbot rustbot added this to the 1.62.0 milestone Apr 7, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (2310da4): comparison url.

Summary:

  • Primary benchmarks: changes not relevant. 2 results were found to be statistically significant but the changes were too small to be relevant.
  • Secondary benchmarks: 🎉 relevant improvements found
Regressions 😿
(primary)
Regressions 😿
(secondary)
Improvements 🎉
(primary)
Improvements 🎉
(secondary)
All 😿 🎉
(primary)
count1 0 0 2 6 2
mean2 N/A N/A -0.4% -1.1% -0.4%
max N/A N/A -0.4% -1.3% -0.4%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

  1. number of relevant changes

  2. the arithmetic mean of the percent change

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-rustdoc Relevant to the rustdoc 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