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 6 pull requests #116566

Closed
wants to merge 99 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

eduardosm and others added 30 commits September 5, 2023 20:06
Those were removed from stdarch in rust-lang/stdarch#1463 (`<*mut _>::write_unaligned` is used instead)
…ediate intrinsics

Those were removed from stdarch in rust-lang/stdarch#1463 (`simd_shl` and `simd_shr` are used instead)
…dtwco,bjorn3

Update stdarch submodule and remove special handling in cranelift codegen for some AVX and SSE2 LLVM intrinsics

rust-lang/stdarch#1463 reimplemented some x86 intrinsics to avoid using some x86-specific LLVM intrinsics:

* Store unaligned (`_mm*_storeu_*`) use `<*mut _>::write_unaligned` instead of `llvm.x86.*.storeu.*`.
* Shift by immediate (`_mm*_s{ll,rl,ra}i_epi*`) use `if` (srl, sll) or `min` (sra) to simulate the behaviour when the RHS is out of range. RHS is constant, so the `if`/`min` will be optimized away.

This PR updates the stdarch submodule to pull these changes and removes special handling for those LLVM intrinsics from cranelift codegen. I left gcc codegen untouched because there are some autogenerated lists.
…orn3

Sync rustc_codegen_cranelift

Not much changed this time. Mostly doing this sync to make it easier to run the entire test suite on the in-tree version.

r? `@ghost`

`@rustbot` label +A-codegen +A-cranelift +T-compiler
Use `Freeze` for `SourceFile`

This uses the `Freeze` type in `SourceFile` to let accessing `external_src` and `lines` be lock-free.

Behavior of `add_external_src` is changed to set `ExternalSourceKind::AbsentErr` on a hash mismatch which matches the documentation. `ExternalSourceKind::Unneeded` was removed as it's unused.

Based on rust-lang#115401.
Remove `verbose_generic_activity_with_arg`

This removes `verbose_generic_activity_with_arg` and changes users to `generic_activity_with_arg`. This keeps the output of `-Z time` readable while these repeated events are still available with the self profiling mechanism.
…iser

add helper method for finding the one non-1-ZST field
Signed-off-by: onur-ozkan <work@onurozkan.dev>
organize import sections with rustfmt `group_imports`
also share the code that emits the actual error
nnethercote and others added 14 commits October 9, 2023 13:47
The `\n` in the output is a little surprising. The next commit will deal
with it.
The assertion in `assert-long-condition.rs` used to be fail like this, all on
one line:
```
thread 'main' panicked at 'assertion failed: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18\n                                + 19 + 20 + 21 + 22 + 23 + 24 + 25 == 0', tests/ui/macros/assert-long-condition.rs:7:5
```
The `\n` and subsequent indent is because the condition is pretty-printed, and
the pretty-printer inserts a newline. Printing the newline in this way is
arguably reasonable given that the message appears within single quotes, which
is very similar to a string literal.

However, after the assertion printing improvements that were released in 1.73,
the assertion now fails like this:
```
thread 'main' panicked at tests/ui/macros/assert-long-condition.rs:7:5:
assertion failed: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18\n                                + 19 + 20 + 21 + 22 + 23 + 24 + 25 == 0
```
Now that there are no single quotes around the pretty-printed condition, the
`\n` is quite strange.

This commit gets rid of the `\n`, by removing the `escape_debug` done on the
pretty-printed message. This results in the following:
```
thread 'main' panicked at tests/ui/macros/assert-long-condition.rs:7:5:
assertion failed: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18
                                + 19 + 20 + 21 + 22 + 23 + 24 + 25 == 0
```
The overly-large indent is still strange, but that's a separate pretty-printing issue.

This change helps with rust-lang#108341.
…piler-errors

improve the suggestion of `generic_bound_failure`

- Fixes rust-lang#115375
- suggest the bound in the correct scope: trait or impl header vs assoc item. See `tests/ui/suggestions/lifetimes/type-param-bound-scope.rs`
- don't suggest a lifetime name that conflicts with the other late-bound regions of the function:
```rust
type Inv<'a> = *mut &'a ();
fn check_bound<'a, T: 'a>(_: T, _: Inv<'a>) {}
fn test<'a, T>(_: &'a str, t: T, lt: Inv<'_>) { // suggests a new name `'a`
    check_bound(t, lt); //~ ERROR
}
```
…ompiler-errors

Fix suggestion span involving wrongly placed generic arg on variant

Fixes rust-lang#116473

The span computation was wrong. It went from the end of the variant to the end of the (wrongly placed) args. However, the variant lived in a different expansion and this resulted in a nonsensical span that overlaps with another and thereby leads to the ICE.

In the fix I've changed span computation to not be based on the location of the variant, but purely on the location of the args. I simply extend the start of the args span 2 positions to the left and that includes the `::` and that's all we need apparently.

This approach produces a correct span regardless of which macro/expansion the args reside in and where the variant is.
… r=matthewjasper

Improve handling of assertion failures with very long conditions

It's not perfectly clear what the best behaviour is here, but I think this is an improvement.

r? ``@matthewjasper``
cc ``@m-ou-se``
…i-obk

Simplify some mir passes by using let chains
…bjorn3

Sync rustc_codegen_cranelift

The highlights this time are improved simd and inline asm support, `is_x86_feature_detected!()` returning the actual cpu features when inline asm support is enabled and a couple of bug fixes.

r? ``@ghost``

``@rustbot`` label +A-codegen +A-cranelift +T-compiler +subtree-sync
…rrors

Add a test for fixed ICE

Addresses rust-lang#115517 (comment)

Closes rust-lang#115517

r? `@compiler-errors`
@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc 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. rollup A PR which is a rollup labels Oct 9, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented Oct 9, 2023

📌 Commit 8973f0e has been approved by matthiaskrgr

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 Oct 9, 2023
@oli-obk
Copy link
Contributor

oli-obk commented Oct 9, 2023

This will fail again, since it includes #116548

@oli-obk
Copy link
Contributor

oli-obk commented Oct 9, 2023

@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 Oct 9, 2023
@matthiaskrgr
Copy link
Member Author

yeet!

@matthiaskrgr matthiaskrgr deleted the rollup-h4j68fm branch March 16, 2024 18:19
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 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.