Rollup of 9 pull requests #133657
Closed
Rollup of 9 pull requests #133657
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
…cludes itself as the tail field
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.
It is unnecessary.
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
added
A-compiletest
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:
extended_varargs_abi_support#116161 (Stabilizeextended_varargs_abi_support)extern_crateon current trait on crate mismatch errors #133585 (Do not callextern_crateon current trait on crate mismatch errors)+forced-atomicsfeature to esp32s2 no_std target #133599 (Add+forced-atomicsfeature to esp32s2 no_std target)parse_expr_bottom. #133623 (Improve span handling inparse_expr_bottom.)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup