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

Automatic Rustup #4175

Merged
merged 10 commits into from
Feb 3, 2025
Merged

Automatic Rustup #4175

merged 10 commits into from
Feb 3, 2025

Conversation

github-actions[bot]
Copy link

@github-actions github-actions bot commented Feb 3, 2025

Please close and re-open this PR to trigger CI, then enable auto-merge.

bjorn3 and others added 10 commits February 2, 2025 16:06
All callers of EarlyDiagCtxt::early_error now emit a fatal error.
… r=jieyouxu

CompileTest: Add Directives to Ignore `arm-unknown-*` Targets

In  #134626, I want to ignore `arm-unknown-*` targets because the LLVM IR for those looks very different compared to other targets: https://rust.godbolt.org/z/ssYMhdv4x.

I can use `ignore-arm` but, I think, it would exclude large number of Apple devices.

So this PR adds a few directives to ignore `arm-unknown-*` targets specifically.
Fix malformed error annotations in a UI test

The compiletest DSL still features a historical remnant from the time when its directives were merely prefixed with `//` instead of `//`@`` when unknown directive names weren't rejected since they could just as well be part of prose:

As an "optimization", it stops looking for directives once it stumbles upon a line which starts with either `fn` or `mod`. This allowed a malformed error annotation of the form `//`@[…]~^^^`` to go undetected & unexercised (as it's placed below `fn main() {`).

Obviously a character other than ``@`` would've mangled the error annotation, too (but it might've caught the reviewer's eye). I specifically found this file because I ran `rg '^(fn|mod)[\s\S]*?//`@'` tests/ui --multiline -trust` to check how footgun-y that "special feature" of compiletest is.
Shorten error message for callable with wrong return type

```
error: expected `{closure@...}` to return `Ret`, but it returns `Other`
```
instead of
```
error: expected `{closure@...}` to be a closure that returns `Ret`, but it returns `Other`
```
Explain why we retroactively change a static initializer to have a different type

I keep getting confused about it and in turn confused `@GuillaumeGomez` while trying to explain it badly
Couple of cleanups to DiagCtxt and EarlyDiagCtxt
Miri subtree update

r? `@ghost`

Unblocks rust-lang/rust#122408 from the Miri side
Rollup of 8 pull requests

Successful merges:

 - #136145 (Test validity of pattern types)
 - #136339 (CompileTest: Add Directives to Ignore `arm-unknown-*` Targets)
 - #136403 (Fix malformed error annotations in a UI test)
 - #136414 (Shorten error message for callable with wrong return type)
 - #136425 (Move `rustc_middle::infer::unify_key`)
 - #136426 (Explain why we retroactively change a static initializer to have a different type)
 - #136445 (Couple of cleanups to DiagCtxt and EarlyDiagCtxt)
 - #136452 (Miri subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup
@rustbot rustbot closed this Feb 3, 2025
@rustbot rustbot reopened this Feb 3, 2025
@oli-obk oli-obk enabled auto-merge February 3, 2025 05:26
@oli-obk oli-obk added this pull request to the merge queue Feb 3, 2025
Merged via the queue into master with commit e4280d9 Feb 3, 2025
7 checks passed
@oli-obk oli-obk deleted the rustup-2025-02-03 branch February 3, 2025 05:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants