Rollup of 10 pull requests #82941
Closed
Rollup of 10 pull requests #82941
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
Currently, on Nightly, this panics:
```
use std::process::ExitStatus;
use std::os::unix::process::ExitStatusExt;
fn main() {
let st = ExitStatus::from_raw(0x007f);
println!("st = {}", st);
}
```
This is because the impl of Display assumes that if .code() is None,
.signal() must be Some. That was a false assumption, although it was
true with buggy code before
5b1316f
unix ExitStatus: Do not treat WIFSTOPPED as WIFSIGNALED
This is not likely to have affected many people in practice, because
`Command` will never produce such a wait status (`ExitStatus`).
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
The use of `ExitStatus` as the Rust type name for a Unix *wait status*, not an *exit status*, is very confusing, but sadly probably too late to change. This area is confusing enough in Unix already (and many programmers are already confuxed). We can at least document it. I chose *not* to mention the way shells like to exit with signal numbers, thus turning signal numbers into exit statuses. This is only relevant for Rust programs using `std::process` if they run shells. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
MacOS uses a different representation. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
If different unices have different bit patterns for WIFSTOPPED and WIFCONTINUED then simply being glibc is probably not good enough for this rather ad-hoc test to work. Do it on Linux only. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
I strongly disagree with tidy in this case but AIUI there is no way to override it. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Rustdoc almost never needs a full stage 2 compiler, and requiring rustdoc tests to be in run-make-fulldeps adds a lot of compile time for no reason.
This switches Rust's WASI target to use crt1-command.o instead of crt1.o, which enables support for new-style commands. By default, new-style commands work the same way as old-style commands, so nothing immediately changes here, but this will be needed by later changes to enable support for typed arguments. See here for more information on new-style commands: - WebAssembly/wasi-libc#203 - https://reviews.llvm.org/D81689
…itionally Co-authored-by: David Tolnay <dtolnay@gmail.com>
LLVM requires at least cmake 3.13.4 and cmake is only required to build LLVM. Also closes rust-lang#42555
…_unsafe_fn, r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn`, as proposed in rust-lang#71668 (comment). Tracking issue: rust-lang#71668 r? ``@nikomatsakis`` cc ``@SimonSapin`` ``@RalfJung`` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently, the body of unsafe functions is an unsafe block, i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint, stabilized here, can be used to change this behavior, so performing unsafe operations in unsafe functions requires an unsafe block. For now, the lint is allow-by-default, which means that this PR does not change anything without overriding the lint level. For more information, see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default, // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here, no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also, no "unused unsafe" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also, no "unused unsafe" warning will be emitted here.) unsafe { unsf(); } } ```
…akis always eagerly eval consts in Relate r? ``@nikomatsakis`` cc ``@varkor``
Deprecate `intrinsics::drop_in_place` and `collections::Bound`, which accidentally weren't deprecated Fixes rust-lang#82080. I've taken the liberty of updating the `since` values to 1.52, since an unobservable deprecation isn't much of a deprecation (even the detailed release notes never bothered to mention these deprecations). As mentioned in the issue I'm *pretty* sure that using a type alias for `Bound` is semantically equivalent to the re-export; [the reference implies](https://doc.rust-lang.org/reference/items/type-aliases.html) that type aliases only observably differ from types when used on unit structs or tuple structs, whereas `Bound` is an enum.
Fixes to ExitStatus and its docs * On Unix, properly display every possible wait status (and don't panic on weird values) * In the documentation, be clear and consistent about "exit status" vs "wait status".
…rk-Simulacrum Build rustdoc for run-make tests, not just run-make-fulldeps Rustdoc almost never needs a full stage 2 compiler, and requiring rustdoc tests to be in run-make-fulldeps adds a lot of compile time for no reason. This is the same change from rust-lang#81197, but separated into its own PR. I ran into this again today while working on rust-lang/docs.rs#1302. r? ``@Mark-Simulacrum``
…=joshtriplett Add Option::get_or_default Tracking issue: rust-lang#82901 The original issue is rust-lang#55042, which was closed, but for an invalid reason (see discussion there). Opening this to reconsider (I hope that's okay). It seems like the only gap for `Option` being "entry-like". I ran into a need for this method where I had a `Vec<Option<MyData>>` and wanted to do `vec[n].get_or_default().my_data_method()`. Using an `Option` as an inner component of a data structure is probably where the need for this will normally arise.
…=jonas-schievink ⬆️ rust-analyzer
…chton WASI: Switch to crt1-command.o to enable support for new-style commands This switches Rust's WASI target to use crt1-command.o instead of crt1.o, which enables support for new-style commands. By default, new-style commands work the same way as old-style commands, so nothing immediately changes here, but this will be needed by later changes to enable support for typed arguments. See here for more information on new-style commands: - WebAssembly/wasi-libc#203 - https://reviews.llvm.org/D81689 r? ``@alexcrichton``
…_readme, r=Mark-Simulacrum Update README.md to use the correct cmake version number LLVM requires at least cmake 3.13.4 and cmake is only required to build LLVM. https://www.llvm.org/docs/CMake.html Also closes rust-lang#42555
…imulacrum Bump tracing-tree dependency This bump fixes two small rendering things that were annoying me: * The first level didn't have an opening line * When wraparound happens, there was no warning, the levels just disappeared. Now there is a line that shows that wraparound is happening See https://github.com/davidbarsky/tracing-tree/pull/31/files for how the look changes
|
@bors r+ rollup=never p=5 |
|
📌 Commit de570f7 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit de570f7 with merge cfd9de773e70c8b649269ce71b6e244fe9a35c0d... |
|
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
|
☔ The latest upstream changes (presumably #82982) made this pull request unmergeable. Please resolve the merge conflicts. |
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:
unsafe_op_in_unsafe_fnlint #79208 (Stabilizeunsafe_op_in_unsafe_fnlint)intrinsics::drop_in_placeandcollections::Bound, which accidentally weren't deprecated #82122 (Deprecateintrinsics::drop_in_placeandcollections::Bound, which accidentally weren't deprecated)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup