Rollup of 10 pull requests #82953
Merged
Rollup of 10 pull requests #82953
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 <[email protected]>
Signed-off-by: Ian Jackson <[email protected]>
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 <[email protected]>
MacOS uses a different representation. Signed-off-by: Ian Jackson <[email protected]>
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 <[email protected]>
I strongly disagree with tidy in this case but AIUI there is no way to override it. Signed-off-by: Ian Jackson <[email protected]>
Add powerpc-unknown-openbsd target * Fix missing abi::endian crate * Missing platform-support.md
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.
…itionally Co-authored-by: David Tolnay <[email protected]>
LLVM requires at least cmake 3.13.4 and cmake is only required to build LLVM. Also closes rust-lang#42555
I'm still not totally sure if this is the right way to implement the memcpy, but that portion compiles correctly now. Now to fix the compile errors everywhere else :).
This updates all places where match branches check on StatementKind or UseContext. This doesn't properly implement them, but adds TODOs where they are, and also adds some best guesses to what they should be in some cases.
Changed to various implementations, copying the style of prior function calls in places I was unsure of. Also one minor style nit.
Fixes copy_non_overlapping codegen_ssa to properly handle pointees, and use bytes instead of elem count
This replaces where it was previously being constructed in intrinsics, with direct construction of the Statement.
It was suggested to lower this in MIR instead of ssa, so do that instead.
Instead of looking for `std::prelude::v1`, this changes it to look for `std::prelude::<anything>`.
Also add some span_bugs where it is unreachable
Add StatementKind::CopyNonOverlapping Implements rust-lang/compiler-team#348 r? `@nagisa`
…_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(); } } ```
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".
Add powerpc-unknown-openbsd target
…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
…_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
…de-v1, r=estebank Don't hardcode the `v1` prelude in diagnostics, to allow for new preludes. Instead of looking for `std::prelude::v1`, this changes the two places where that was hardcoded to look for `std::prelude::<anything>` instead. This is needed for rust-lang#82217. r? `@estebank`
|
@bors r+ rollup=never p=10 |
|
📌 Commit 9dc82fa has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
rust-highfive
added a commit
to rust-lang-nursery/rust-toolstate
that referenced
this pull request
Mar 10, 2021
Tested on commit rust-lang/rust@861872b. Direct link to PR: <rust-lang/rust#82953> 💔 miri on windows: test-pass → test-fail (cc @eddyb @RalfJung @oli-obk). 💔 miri on linux: test-pass → test-fail (cc @eddyb @RalfJung @oli-obk).
This was referenced Mar 10, 2021
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)v1prelude in diagnostics, to allow for new preludes. #82942 (Don't hardcode thev1prelude in diagnostics, to allow for new preludes.)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup