-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Rollup of 5 pull requests #95745
Commits on Mar 21, 2022
-
Configuration menu - View commit details
-
Copy full SHA for 2437422 - Browse repository at this point
Copy the full SHA 2437422View commit details
Commits on Apr 3, 2022
-
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.
Configuration menu - View commit details
-
Copy full SHA for 34bcc8e - Browse repository at this point
Copy the full SHA 34bcc8eView commit details
Commits on Apr 6, 2022
-
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.
Configuration menu - View commit details
-
Copy full SHA for b72a7fb - Browse repository at this point
Copy the full SHA b72a7fbView commit details -
Configuration menu - View commit details
-
Copy full SHA for f87d180 - Browse repository at this point
Copy the full SHA f87d180View commit details -
Revert "Mark Location::caller() as #[inline]"
This reverts commit 6d0b61e.
Configuration menu - View commit details
-
Copy full SHA for 6a7ff98 - Browse repository at this point
Copy the full SHA 6a7ff98View commit details -
Configuration menu - View commit details
-
Copy full SHA for d48a39a - Browse repository at this point
Copy the full SHA d48a39aView commit details -
Configuration menu - View commit details
-
Copy full SHA for 56d0f94 - Browse repository at this point
Copy the full SHA 56d0f94View commit details -
Configuration menu - View commit details
-
Copy full SHA for e8a6f53 - Browse repository at this point
Copy the full SHA e8a6f53View commit details -
Rollup merge of rust-lang#95185 - m-ou-se:stabilize-stdin-lines, r=Ma…
…rk-Simulacrum Stabilize Stdin::lines. Closes rust-lang#87096 Fcp completed here: rust-lang#87096 (comment)
Configuration menu - View commit details
-
Copy full SHA for d2f1a0b - Browse repository at this point
Copy the full SHA d2f1a0bView commit details -
Rollup merge of rust-lang#95626 - saethlin:pass-pointer-to-prctl, r=c…
…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.
Configuration menu - View commit details
-
Copy full SHA for 64e7bf9 - Browse repository at this point
Copy the full SHA 64e7bf9View commit details -
Rollup merge of rust-lang#95709 - nnethercote:improve-terse-test-outp…
…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.
Configuration menu - View commit details
-
Copy full SHA for 687e40a - Browse repository at this point
Copy the full SHA 687e40aView commit details -
Rollup merge of rust-lang#95735 - bjorn3:revert_inline_location_calle…
…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.
Configuration menu - View commit details
-
Copy full SHA for b22df08 - Browse repository at this point
Copy the full SHA b22df08View commit details -
Rollup merge of rust-lang#95738 - GuillaumeGomez:item-info-switch-to-…
…span, r=jsha Switch item-info from div to span Following discussion in rust-lang#95684. cc `@jsha` r? `@notriddle`
Configuration menu - View commit details
-
Copy full SHA for fe6d69f - Browse repository at this point
Copy the full SHA fe6d69fView commit details