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 #126307

Closed
wants to merge 23 commits into from

Conversation

workingjubilee
Copy link
Contributor

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

mgeier and others added 23 commits April 2, 2024 18:54
People keep making fun of this signature for being so gnarly.
Associated type bounds lend it a much simpler scribbling.
ChangeOutputType can also come along for the ride.
Instead of not generating the function at all on big endian (which
makes the CHECK lines fail), instead use to_le() on big endian,
so that we essentially perform a bswap for both endiannesses.
Currently it can be made to fail by rearranging code within
`compiler/rustc_mir_transform/src/lint.rs`.
PR rust-lang#125443 will reformat all the use declarations in the repo. This
would break a patch kept in `rustc_codegen_cranelift` that gets applied
to `library/std/src/sys/pal/windows/rand.rs`.

So this commit formats the use declarations in
`library/std/src/sys/pal/windows/rand.rs` in advance of rust-lang#125443 and
updates the patch file accordingly.

The motivation is that rust-lang#125443 is a huge change and we want to get
fiddly little changes like this out of the way so it can be nothing more
than an `x fmt --all`.
For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.

Adding suggestions for following function in E0277.

```rust
fn main() {
    let mut _file = File::create("foo.txt")?;
}
```

to

```rust
fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut _file = File::create("foo.txt")?;

    return Ok(());
}
```

According to the issue rust-lang#125997, only the code examples in the issue are targeted, but the issue covers a wider range of situations.

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->
…=workingjubilee

docs(core): make more const_ptr doctests assert instead of printing

improves on rust-lang#124669
…s, r=compiler-errors

Provide correct parent for nested anon const

Fixes rust-lang#126147

99% of this PR is just comments explaining what the issue is.

`tcx.parent(` and `hir().get_parent_item(` give different results as the hir owner for all the hir of anon consts is the enclosing function. I didn't attempt to change that as being a hir owner requires a `DefId` and long term we want to stop creating anon consts' `DefId`s before hir ty lowering.

So i just opted to change `generics_of` to use `tcx.parent` to get the parent for `AnonConst`'s. I'm not entirely sure about this being what we want, it does seem weird that we have two ways of getting the parent of an `AnonConst` and they both give different results.

Alternatively we could just go ahead and make `const_evaluatable_unchecked` a hard error and stop providing generics to repeat exprs. Then this isn't an issue. (The FCW has been around for almost 4 years now)

r? ```@compiler-errors```
…gnature, r=scottmcm

Simplify `[T; N]::try_map` signature

People keep making fun of this signature for being so gnarly.
Associated type bounds admit a much simpler scribbling.

r? ```@scottmcm```
…tlarsan68

Add {{target}} substitution to compiletest

In ferrocene we have ui tests testing the cli interface of the compiler, one of which tests the `--target` flag. To be able to run this on all targets we require a way to specify a valid target in the `compile-flags` directive that is target independent, as otherwise we can only run the test against the one target we choose to supply in the flags. See https://github.com/ferrocene/ferrocene/blob/383cbc80f4e85859a4055f121f15dac329908346/tests/ui/ferrocene/compiler-arguments/target/target.rs

We figured the project might be able to make use of this substitution as well in the future.

try-job: dist-x86_64-msvc
…eyouxu

Make issue-122805.rs big endian compatible

Instead of not generating the function at all on big endian (which makes the CHECK lines fail), instead use to_le() on big endian, so that we essentially perform a bswap for both endiannesses.
set_env: State the conclusion upfront

People tend to skim or skip over long explanations so we should be very upfront that `set_var` and `remove_var` are being made unsafe for a very good reason.

This is just the conclusion restated almost verbatim but earlier in the docs and separated from the explanation:

https://github.com/rust-lang/rust/blob/0c960618b56f662d933e8b864cd9632a99174e87/library/std/src/env.rs#L338-L339

I think this may help with people who may not be entirely comfortable with rust-lang#125937 being rejected.
Make `storage-live.rs` robust against rustc internal changes.

Currently it can be made to fail by rearranging code within `compiler/rustc_mir_transform/src/lint.rs`.

This is a precursor to rust-lang#125443.

r? ``@lqd``
…ch, r=bjorn3

Update a cranelift patch file for formatting changes.

PR rust-lang#125443 will reformat all the use declarations in the repo. This would break a patch kept in `rustc_codegen_cranelift` that gets applied to `library/std/src/sys/pal/windows/rand.rs`.

So this commit formats the use declarations in `library/std/src/sys/pal/windows/rand.rs` in advance of rust-lang#125443 and updates the patch file accordingly.

The motivation is that rust-lang#125443 is a huge change and we want to get fiddly little changes like this out of the way so it can be nothing more than an `x fmt --all`.

r? `@bjorn3`
@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc O-windows Operating system: Windows S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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. rollup A PR which is a rollup labels Jun 12, 2024
@workingjubilee
Copy link
Contributor Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Jun 12, 2024

📌 Commit 54f92f9 has been approved by workingjubilee

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2024
@workingjubilee
Copy link
Contributor Author

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 12, 2024
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 O-windows Operating system: Windows rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants