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 10 pull requests #82953

Merged
merged 36 commits into from
Mar 10, 2021
Merged

Rollup of 10 pull requests #82953

merged 36 commits into from
Mar 10, 2021

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

LeSeulArtichaut and others added 30 commits February 18, 2021 17:12
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>
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 <dtolnay@gmail.com>
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.
…_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`
@rustbot rustbot added the rollup A PR which is a rollup label Mar 9, 2021
@JohnTitor
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Mar 9, 2021

📌 Commit 9dc82fa has been approved by JohnTitor

@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 Mar 9, 2021
@bors
Copy link
Contributor

bors commented Mar 10, 2021

⌛ Testing commit 9dc82fa with merge 861872b...

@bors
Copy link
Contributor

bors commented Mar 10, 2021

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 861872b to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 10, 2021
@bors bors merged commit 861872b into rust-lang:master Mar 10, 2021
@rustbot rustbot added this to the 1.52.0 milestone Mar 10, 2021
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #82953!

Tested on commit 861872b.
Direct link to PR: #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).

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.