Skip to content

Rollup of 9 pull requests #133657

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 608 commits into from
Closed

Rollup of 9 pull requests #133657

wants to merge 608 commits into from

Conversation

jieyouxu
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ehuss and others added 30 commits November 25, 2024 09:31
Foreword
========

Let us begin the journey to rediscover what the `//@ pretty-expanded`
directive does, brave traveller --

    "My good friend, [..] when I wrote that passage, God and I knew what
    it meant. It is possible that God knows it still; but as for me, I
    have totally forgotten."

                                 -- Johann Paul Friedrich Richter, 1826

We must retrace the steps of those before us, for history shall guide us
in the present and inform us of the future.

The Past
========

Originally there was some effort to introduce more test coverage for `-Z
unpretty=expanded` (in 2015 this was called `--pretty=expanded`). In
[Make it an error to not declare used features rust-lang#23598][pr-23598], there
was a flip from `//@ no-pretty-expanded` (opt-out of `-Z
unpretty=expanded` test) to `//@ pretty-expanded` (opt-in to `-Z
unpretty=expanded` test). This was needed because back then the
dedicated `tests/pretty` ("pretty") test suite did not existed, and the
pretty tests were grouped together under `run-pass` tests (I believe
`ui` test suite didn't exist back then either). Unfortunately, in this
process the replacement `//@ pretty-expanded` directives contained a
`FIXME rust-lang#23616` linking to [There are very few tests for `-Z unpretty`
expansion rust-lang#23616][issue-23616]. But this was arguably backwards and
somewhat misleading, as noted in
<rust-lang#23616 (comment)>:

    The attribute is off by default and things just work if you don't
    test it, people have not been adding the `pretty-expanded`
    annotation to new tests even if it would work.

Which basically renders this useless.

The Present
===========

As of Nov 2024, we have a dedicated `pretty` test suite, and some time
over the years the split between `run-pass` into `ui` and `pretty` test
suites caused all of the `//@ pretty-expanded` in `ui` tests to do
absolutely nothing -- the compiletest logic for `pretty-expanded` only
triggered in the *pretty* test suite, but none of the pretty tests use
it. Oops.

The Future
==========

Nobody remembers this, nobody uses this, it's misleading in ui tests.
Let's get rid of this directive altogether.

[pr-23598]: rust-lang#23598
[issue-23616]: rust-lang#23616
Done with

```bash
sd '//@ pretty-expanded.*\n' '' tests/ui/**/*.rs
```

and

```
sd '//@pretty-expanded.*\n' '' tests/ui/**/*.rs
```
fix: Fix a stack overflow when computing the sizedness of a struct that includes itself as the tail field
…ang#13722)

Fix rust-lang#13706

changelog: [`trait_duplication_in_bounds`]: fix ICE on duplicate type or
constant bound
Found while reading code: the comment was incorrect as it stops counting
as soon as two elements are different.

changelog: none
The linker has been randomly crashing on `x86_64-mingw` that's causing
spurious failures. Disable this test on Windows for now.
They are always called in succession, so it's simpler if they are merged
into a single function.
Describing some things that took me a long time to understand.
In `MaybeRequiresStorage::apply_before_statement_effect`, call
`transfer_function` directly, as is already done in
`MaybeRequiresStorage::apply_before_terminator_effect`. This makes it clear
that the operation doesn't rely on the `MaybeBorrowedLocals` results.
`ResultsCursor` currently owns its `Results`. But sometimes the
`Results` is needed again afterwards. So there is
`ResultsCursor::into_results` for extracting the `Results`, which leads
to some awkwardness.

This commit adds `ResultsHandle`, a `Cow`-like type that can either
borrow or own a a `Results`. `ResultsCursor` now uses it. This is good
because some `ResultsCursor`s really want to own their `Results`, while
others just want to borrow it.

We end with with a few more lines of code, but get some nice cleanups.
- `ResultsCursor::into_results` and `Formatter::into_results` are
  removed.
- `write_graphviz_results` now just borrows a `Results`, instead of the
  awkward "take ownership of a `Results` and then return it unchanged"
  pattern.

This reinstates the cursor flexibility that was lost in rust-lang#118230 -- which
removed the old `ResultsRefCursor` and `ResultsCloneCursor` types -- but
in a much simpler way. Hooray!
We can union the two sets the easy way. This removes the need for the
domain size check, because `union` does that same check itself.
It's very closely related to `MaybeStorageLive` and `MaybeStorageDead`.
It's weird that it's currently in a different module.
Fix target_feature handling in freg of LoongArch inline assembly

In LoongArch inline assembly, freg currently always accepts f32/f64 as input/output.

https://github.com/rust-lang/rust/blob/9b4d7c6a40b328d212095c28670c629facf1557d/compiler/rustc_target/src/asm/loongarch.rs#L41

However, these types actually require f/d target features as in RISC-V.
Otherwise, an (ugly) compile error will occur: https://godbolt.org/z/K61Gq1E9E

f32/f64 without f:

```
error: couldn't allocate output register for constraint '{$f1}'
  --> <source>:12:11
   |
12 |     asm!("", in("$f1") x, lateout("$f1") y);
   |           ^
```

f64 with f but without d:

```
error: scalar-to-vector conversion failed, possible invalid constraint for vector type
  --> <source>:19:11
   |
19 |     asm!("", in("$f1") x, lateout("$f1") y);
   |           ^
```

cc `@heiher`

r? `@Amanieu`

`@rustbot` label +O-LoongArch +A-inline-assembly
…cs, r=Amanieu

Add `+forced-atomics` feature to esp32s2 no_std  target

Similar to rust-lang#114499 but for the Xtensa backend. The ESP32-S2 doesn't have native atomic support, but can have atomic load/stores as part of the ISA with this LLVM codegen feature.

Note: The current rev of LLVM that rustc is using doesn't contain the `+forced-atomics` feature for Xtensa, but I'm pushing this now to remove the patch from our fork in `esp-rs/rust`.

r? `@Amanieu` because you reviewed the related RISC-V PR
…to_variadic_function, r=compiler-errors

Simplify hir_typeck_pass_to_variadic_function

r? `@compiler-errors`
This reworks a bit how the diagnostic is generated so that it does the same as rust-lang#133538

The `help` is useless now so I removed it
…s, r=compiler-errors

Improve span handling in `parse_expr_bottom`.

`parse_expr_bottom` stores `this.token.span` in `lo`, but then fails to use it in many places where it could. This commit fixes that, and likewise (to a smaller extent) in `parse_ty_common`.

r? `@spastorino`
…compiler-errors

custom MIR: add doc comment for debuginfo

This is a revival of rust-lang#117015
@rustbot rustbot added A-compiletest Area: The compiletest test runner A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-json Area: Rustdoc JSON backend A-testsuite Area: The testsuite used to check the correctness of rustc O-apple Operating system: Apple (macOS, iOS, tvOS, visionOS, watchOS) O-hermit Operating System: Hermit O-SGX Target: SGX O-solid Operating System: SOLID O-unix Operating system: Unix-like O-wasi Operating system: Wasi, Webassembly System Interface O-windows Operating system: Windows PG-exploit-mitigations Project group: Exploit mitigations 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-infra Relevant to the infrastructure 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-release Relevant to the release subteam, 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) rollup A PR which is a rollup labels Nov 30, 2024
@jieyouxu jieyouxu closed this Nov 30, 2024
@jieyouxu jieyouxu deleted the rollup-lhzu56r branch November 30, 2024 04:55
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-compiletest Area: The compiletest test runner A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-json Area: Rustdoc JSON backend A-testsuite Area: The testsuite used to check the correctness of rustc O-apple Operating system: Apple (macOS, iOS, tvOS, visionOS, watchOS) O-hermit Operating System: Hermit O-SGX Target: SGX O-solid Operating System: SOLID O-unix Operating system: Unix-like O-wasi Operating system: Wasi, Webassembly System Interface O-windows Operating system: Windows PG-exploit-mitigations Project group: Exploit mitigations rollup A PR which is a rollup 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-infra Relevant to the infrastructure 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-release Relevant to the release subteam, 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.