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 7 pull requests #103471

Merged
merged 142 commits into from
Oct 24, 2022
Merged

Rollup of 7 pull requests #103471

merged 142 commits into from
Oct 24, 2022

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

steffahn and others added 30 commits July 22, 2022 01:35
The lifetime bound `B::Owned: 'a` is redundant and doesn't make a difference,
because `Cow<'a, B>` comes with an implicit `B: 'a`, and associated types
will outlive lifetimes outlived by the `Self` type (and all the trait's
generic parameters, of which there are none in this case), so the implicit `B: 'a`
implies `B::Owned: 'a` anyway.

The explicit lifetime bound here does however end up in documentation,
and that's confusing in my opinion, so let's remove it ^^
This commit adds the following functions all of which have a signature
`pointer, usize -> pointer`:
- `<*mut T>::mask`
- `<*const T>::mask`
- `intrinsics::ptr_mask`

These functions are equivalent to `.map_addr(|a| a & mask)` but they
utilize `llvm.ptrmask` llvm intrinsic.

*masks your pointers*
Co-authored-by: bjorn3 <[email protected]>
Because `PassMode::Cast` is by far the largest variant, but is
relatively rare.

This requires making `PassMode` not impl `Copy`, and `Clone` is no
longer necessary. This causes lots of sigil adjusting, but nothing very
notable.
Because it's only needed for that variant. This shrinks the types and
clarifies the logic.
Shrink `FnAbi`

Because they can take up a lot of memory in debug and release builds.

r? `@bjorn3`
and show some extra information when it happens in CTFE
Add pointer masking convenience functions

This PR adds the following public API:
```rust
impl<T: ?Sized> *const T {
    fn mask(self, mask: usize) -> *const T;
}

impl<T: ?Sized> *mut T {
    fn mask(self, mask: usize) -> *const T;
}

// mod intrinsics
fn mask<T>(ptr: *const T, mask: usize) -> *const T
```
This is equivalent to `ptr.map_addr(|a| a & mask)` but also uses a cool llvm intrinsic.

Proposed in rust-lang#95643 (comment)

cc `@Gankra` `@scottmcm` `@RalfJung`

r? rust-lang/libs-api
… jit

This avoids having to parse the dylibs to get all symbols and matches
the way the dynamic linker resolves symbols. Furthermore it fixes the
jit on Windows.
Use pull instead of push based model for getting dylib symbols in the jit
This makes it possible to instruct libstd to never touch the signal
handler for `SIGPIPE`, which makes programs pipeable by default (e.g.
with `./your-program | head -n 1`) without `ErrorKind::BrokenPipe`
errors.
Replace `Body::basic_blocks()` with field access

Since the refactoring in rust-lang#98930, it is possible to borrow the basic blocks
independently from other parts of MIR by accessing the `basic_blocks` field
directly.

Replace unnecessary `Body::basic_blocks()` method with a direct field access,
which has an additional benefit of borrowing the basic blocks only.
…oli-obk

interpret: make read-pointer-as-bytes a CTFE-only error with extra information

Next step in the reaction to rust-lang#99923. Also teaches Miri to implicitly strip provenance in more situations when transmuting pointers to integers, which fixes rust-lang/miri#2456.

Pointer-to-int transmutation during CTFE now produces a message like this:
```
   = help: this code performed an operation that depends on the underlying bytes representing a pointer
   = help: the absolute address of a pointer is not known at compile-time, so such operations are not supported
```

r? ``@oli-obk``
This PR will fix some typos detected by [typos].

I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.

[typos]: https://github.com/crate-ci/typos
…phize, r=davidtwco

Migrate rustc_monomorphize to use SessionDiagnostic

### Description

- Migrates diagnostics in `rustc_monomorphize` to use `SessionDiagnostic`
- Adds an `impl IntoDiagnosticArg for PathBuf`

### TODO / Help!
- [x] I'm having trouble figuring out how to apply an optional note. 😕  Help!?
  - Resolved. It was bad docs. Fixed in https://github.com/rust-lang/rustc-dev-guide/pull/1437/files
- [x] `errors:RecursionLimit` should be `#[fatal ...]`, but that doesn't exist so it's `#[error ...]` at the moment.
  - Maybe I can switch after this is merged in? --> rust-lang#100694
  - Or maybe I need to manually implement `SessionDiagnostic` instead of deriving it?
- [x] How does one go about converting an error inside of [a call to struct_span_lint_hir](https://github.com/rust-lang/rust/blob/8064a495086c2e63c0ef77e8e82fe3b9b5dc535f/compiler/rustc_monomorphize/src/collector.rs#L917-L927)?
- [x] ~What placeholder do you use in the fluent template to refer to the value in a vector? It seems like [this code](https://github.com/rust-lang/rust/blob/0b79f758c9aa6646606662a6d623a0752286cd17/compiler/rustc_macros/src/diagnostics/diagnostic_builder.rs#L83-L114) ought to have the answer (or something near it)...but I can't figure it out.~ You can't. Punted.
Fix a bunch of typo

This PR will fix some typos detected by [typos].

I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.

[typos]: https://github.com/crate-ci/typos
This updates a test expectation for s390x
The current main branch of Cranelift changed it's signature. Removing
it's use is the easiest way to deal with this.
This fixes a borrowck error with the current main branch of Cranelift.
Recently, another Miri user was trying to run `cargo miri test` on the
crate `iced-x86` with `--features=code_asm,mvex`. This configuration has
a startup time of ~18 minutes. That's ~18 minutes before any tests even
start to run. The fact that this crate has over 26,000 tests and Miri is
slow makes a lot of code which is otherwise a bit sloppy but fine into a
huge runtime issue.

Sorting the tests when the test harness is created instead of at startup
time knocks just under 4 minutes out of those ~18 minutes. I have ways
to remove most of the rest of the startup time, but this change requires
coordinating changes of both the compiler and libtest, so I'm sending it
separately.
jruderman and others added 8 commits October 24, 2022 01:06
…thomcc

Remove redundant lifetime bound from `impl Borrow for Cow`

The lifetime bound `B::Owned: 'a` is redundant and doesn't make a difference,
because `Cow<'a, B>` comes with an implicit `B: 'a`, and associated types
will outlive lifetimes outlived by the `Self` type (and all the trait's
generic parameters, of which there are none in this case), so the implicit `B: 'a`
implies `B::Owned: 'a` anyway.

The explicit lifetime bound here does however [end up in documentation](https://doc.rust-lang.org/std/borrow/enum.Cow.html#impl-Borrow%3CB%3E),
and that's confusing in my opinion, so let's remove it ^^

_(Documentation right now, compare to `AsRef`, too:)_
![Screenshot_20220722_014055](https://user-images.githubusercontent.com/3986214/180332665-424d0c05-afb3-40d8-a330-a57a2c9a494b.png)
…ackh726

Sort tests at compile time, not at startup

Recently, another Miri user was trying to run `cargo miri test` on the crate `iced-x86` with `--features=code_asm,mvex`. This configuration has a startup time of ~18 minutes. That's ~18 minutes before any tests even start to run. The fact that this crate has over 26,000 tests and Miri is slow makes a lot of code which is otherwise a bit sloppy but fine into a huge runtime issue.

Sorting the tests when the test harness is created instead of at startup time knocks just under 4 minutes out of those ~18 minutes. I have ways to remove most of the rest of the startup time, but this change requires coordinating changes of both the compiler and libtest, so I'm sending it separately.

(except for doctests, because there is no compile-time harness)
…on-try-from-secs-float, r=dtolnay

Stabilize `duration_checked_float`

## Stabilization Report

This stabilization report is for a stabilization of `duration_checked_float`, tracking issue: rust-lang#83400.

### Implementation History

- rust-lang#82179
- rust-lang#90247
- rust-lang#96051
- Changed error type to `FromFloatSecsError` in rust-lang#90247
- rust-lang#96051 changes the rounding mode to round-to-nearest instead of truncate.

## API Summary

This stabilization report proposes the following API to be stabilized in `core`, along with their re-exports in `std`:

```rust
// core::time

impl Duration {
    pub const fn try_from_secs_f32(secs: f32) -> Result<Duration, TryFromFloatSecsError>;
    pub const fn try_from_secs_f64(secs: f64) -> Result<Duration, TryFromFloatSecsError>;
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct TryFromFloatSecsError { ... }

impl core::fmt::Display for TryFromFloatSecsError { ... }
impl core::error::Error for TryFromFloatSecsError { ... }
```

These functions are made const unstable under `duration_consts_float`, tracking issue rust-lang#72440.

There is an open question in the tracking issue around what the error type should be called which I was hoping to resolve in the context of an FCP.

In this stabilization PR, I have altered the name of the error type to `TryFromFloatSecsError`. In my opinion, the error type shares the name of the method (adjusted to accommodate both types of floats), which is consistent with other error types in `core`, `alloc` and `std` like `TryReserveError` and `TryFromIntError`.

## Experience Report

Code such as this is ready to be converted to a checked API to ensure it is panic free:

```rust
impl Time {
    pub fn checked_add_f64(&self, seconds: f64) -> Result<Self, TimeError> {
        // Fail safely during `f64` conversion to duration
        if seconds.is_nan() || seconds.is_infinite() {
            return Err(TzOutOfRangeError::new().into());
        }

        if seconds.is_sign_positive() {
            self.checked_add(Duration::from_secs_f64(seconds))
        } else {
            self.checked_sub(Duration::from_secs_f64(-seconds))
        }
    }
}
```

See: artichoke/artichoke#2194.

`@rustbot` label +T-libs-api -T-libs

cc `@mbartlett21`
…acrum

Don't link to `libresolv` in libstd on Darwin

Currently we link `libresolv` into every Rust program on apple targets despite never using it (as of rust-lang#44965). I had thought we needed this for `getaddrinfo` or something, but we do not / cannot safely use it.

I'd like to fix this for `libiconv` too (the other library we pull in. that's harder since it's coming in through `libc`, which is rust-lang/libc#2944)).

---

This may warrant release notes. I'm not sure but I've added the flag regardless -- It's a change to the list of dylibs every Rust program pulls in, so it's worth mentioning.

It's pretty unlikely anybody was relying on this being pulled in, and `std` does not guarantee that it will link (and thus transitively provide access to) any particular system library -- anybody relying on that behavior would already be broken when dynamically linking std. That is, there's an outside chance something will fail to link on macOS and iOS because it was accidentally relying on our unnecessary dependency.

(If that *does* happen, that project could be easily fixed by linking libresolv explicitly on those platforms, probably via `#[link(name = "resolv")] extern {}`,` -Crustc-link-lib=resolv`, `println!("cargo:rustc-link-lib=resolv")`, or one of several places in `.config/cargo.toml`)

---

I'm also going to preemptively add the nomination for discussing this in the libs meeting. Basically: Do we care about programs that assume we will bring libraries in that we do not use. `libresolv` and `libiconv` on macOS/iOS are in this camp (`libresolv` because we used to use it, and `libiconv` because the `libc` crate was unintentionally(?) pulling it in to every Rust program).

I'd like to remove them both, but this may cause link issues programs that are relying on `std` to depend on them transitively. (Relying on std for this does not work in all build configurations, so this seems very fragile, and like a use case we should not support).

More generally, IMO we should not guarantee the specific set of system-provided libraries we use (beyond what is implied by an OS version requirement), which means we'd be free to remove this cruft.
…acrum

Update libstd's libc to 0.2.135 (to make `libstd` no longer pull in `libiconv.dylib` on Darwin)

This is to pull in rust-lang/libc#2944.

It's related to rust-lang#102766, in that they both remove unused dylibs from libstd on Darwin platforms. As a result, I'm marking this as relnotes since everybody agreed it was good to add it to the other as well. (The note should be about no longer linking against libiconv -- the libc update is irrelevant).

Might as well have the same reviewer too.

r? `@Mark-Simulacrum`
…bjorn3

Sync rustc_codegen_cranelift

r? `@ghost`

`@rustbot` label +A-codegen +A-cranelift +T-compiler
Fix grammar in docs for std::io::Read

Two independent clauses were incorrectly joined by a bare comma. The simplest fix would be to switch to a semicolon, but I think it's slightly better to keep the comma and use the coordinating conjunction "so".
@rustbot rustbot added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) A-testsuite Area: The testsuite used to check the correctness of rustc T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Oct 24, 2022
@JohnTitor
Copy link
Member Author

@bors r+ p=7 rollup=never

@bors
Copy link
Contributor

bors commented Oct 24, 2022

📌 Commit a710f56 has been approved by JohnTitor

It is now in the queue for this repository.

@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 Oct 24, 2022
@bors
Copy link
Contributor

bors commented Oct 24, 2022

⌛ Testing commit a710f56 with merge 1481fd9...

@bors
Copy link
Contributor

bors commented Oct 24, 2022

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 1481fd9 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 24, 2022
@bors bors merged commit 1481fd9 into rust-lang:master Oct 24, 2022
@rustbot rustbot added this to the 1.66.0 milestone Oct 24, 2022
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Perf Build Sha
#103466 3a2cf55a19fc1a2bdfd6872543523e6af252a336
#103437 10b13ac6872fcbaa0c504dd5bbfcbc874dca733c
#103277 61d1d6a174e2be32d0a15754d0218cf461d51672
#102766 fd95ae449a840ed22fd1f31e887f4c771a46f231
#102271 0ae83c23ad02839c3d3e34178a7fd3ae9af49802
#99939 5422928f90b0e988643a572f85817f6846900264
#99578 1647e06fc7da6d86c7892cdadaf53a31e4879e81
#100730 ❌ conflicts merging '8c93170965' into previous master ❌
#101101 ❌ conflicts merging '94f2fef4cc' into previous master ❌
#99027 ❌ conflicts merging '1071c4c10b' into previous master ❌

previous master: 4b5fcae32d

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (1481fd9): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.0% [0.2%, 1.9%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.5% [2.5%, 2.5%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.8% [-2.8%, -2.8%] 1
All ❌✅ (primary) - - 0

Cycles

This benchmark run did not return any relevant results for this metric.

Footnotes

  1. the arithmetic mean of the percent change 2

  2. number of relevant changes 2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc 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-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. 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.