Commit Graph

265 Commits

Author SHA1 Message Date
Matthias Krüger
448aa30b5a
Rollup merge of #138162 - ehuss:library-2024, r=cuviper
Update the standard library to Rust 2024

This updates the standard library to Rust 2024. This includes the following notable changes:

- Macros are updated to use new expression fragment specifiers. This PR includes a test to illustrate the changes, primarily allowing `const {...}` expressions now.
- Some tests show a change in MIR drop order. We do not believe this will be an observable change ([see zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/268952-edition/topic/standard.20library.20migration/near/500972873)).

Fixes https://github.com/rust-lang/rust/issues/133081
2025-03-13 10:58:21 +01:00
bors
aaa2d47dae Auto merge of #138083 - nnethercote:rm-NtItem-NtStmt, r=petrochenkov
Remove `NtItem` and `NtStmt`

Another piece of #124141.

r? `@petrochenkov`
2025-03-12 14:18:36 +00:00
Eric Huss
f505d4e8e3 Migrate alloc to Rust 2024 2025-03-11 09:46:34 -07:00
Eric Huss
0e071c2c6a Migrate core to Rust 2024 2025-03-11 09:46:34 -07:00
Eric Huss
590b277d25 Add a test for new 2024 standard library behavior
When migrating the standard library to 2024, there will be some behavior
changes that users will be able to observe. This test should cover that
(I cannot think of any other observable differences).
2025-03-11 09:46:30 -07:00
Esteban Küber
f1c751bc1a Refactor emitter to better account for unicode chars when trimming
Change the way that underline positions are calculated by delaying using
the "visual" column position until the last possible moment, instead
using the "file"/byte position in the file, and then calculating visual
positioning as late as possible. This should make the underlines more
resilient to non-1-width unicode chars.

Unfortunately, as part of this change (which fixes some visual bugs)
comes with the loss of some eager tab codepoint handling, but the output
remains legible despite some minor regression on the "margin trimming"
logic.
2025-03-07 17:55:08 +00:00
Nicholas Nethercote
141719f68a Remove NtItem and NtStmt.
This involves replacing `nt_pretty_printing_compatibility_hack` with
`stream_pretty_printing_compatibility_hack`.

The handling of statements in `transcribe` is slightly different to
other nonterminal kinds, due to the lack of `from_ast` implementation
for empty statements.

Notable test changes:
- `tests/ui/proc-macro/expand-to-derive.rs`: the diff looks large but
  the only difference is the insertion of a single invisible-delimited
  group around a metavar.
2025-03-07 14:51:07 +11:00
Michael Goulet
e4dfca8ac2 Point out macro expansion ident in resolver errors too 2025-03-03 23:53:42 +00:00
Nicholas Nethercote
50076cdeb9 Remove NtPath. 2025-02-28 08:42:14 +11:00
Nicholas Nethercote
ef1114a964 Remove NtPat.
The one notable test change is `tests/ui/macros/trace_faulty_macros.rs`.
This commit removes the complicated `Interpolated` handling in
`expected_expression_found` that results in a longer error message. But
I think the new, shorter message is actually an improvement.

The original complaint was in #71039, when the error message started
with "error: expected expression, found `1 + 1`". That was confusing
because `1 + 1` is an expression. Other than that, the reporter said
"the whole error message is not too bad if you ignore the first line".

Subsequently, extra complexity and wording was added to the error
message. But I don't think the extra wording actually helps all that
much. In particular, it still says of the `1+1` that "this is expected
to be expression". This repeats the problem from the original complaint!

This commit removes the extra complexity, reverting to a simpler error
message. This is primarily because the traversal is a pain without
`Interpolated` tokens. Nonetheless, I think the error message is
*improved*. It now starts with "expected expression, found `pat`
metavariable", which is much clearer and the real problem. It also
doesn't say anything specific about `1+1`, which is good, because the
`1+1` isn't really relevant to the error -- it's the `$e:pat` that's
important.
2025-02-28 08:36:12 +11:00
Nicholas Nethercote
76b04437be Remove NtTy.
Notes about tests:

- tests/ui/parser/macro/trait-object-macro-matcher.rs: the syntax error
  is duplicated, because it occurs now when parsing the decl macro
  input, and also when parsing the expanded decl macro. But this won't
  show up for normal users due to error de-duplication.

- tests/ui/associated-consts/issue-93835.rs: similar, plus there are
  some additional errors about this very broken code.

- The changes to metavariable descriptions in #132629 are now visible in
  error message for several tests.
2025-02-21 15:49:46 +11:00
Nicholas Nethercote
c7981d6411 Remove NtVis.
We now use invisible delimiters for expanded `vis` fragments, instead of
`Token::Interpolated`.
2025-02-21 15:49:44 +11:00
Michael Goulet
6d71251cf9 Trim suggestion parts to the subset that is purely additive 2025-02-14 00:44:10 -08:00
Michael Goulet
b480a9214a Use underline suggestions for purely 'additive' replacements 2025-02-14 00:27:13 -08:00
Esteban Küber
f0845adb0c Show diff suggestion format on verbose replacement
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
  --> $DIR/attempted-access-non-fatal.rs:7:15
   |
LL |     let _ = 2.l;
   |               ^
   |
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
   |
LL -     let _ = 2.l;
LL +     let _ = 2.0f64;
   |
```
2025-02-10 20:21:39 +00:00
Esteban Küber
3815ed63ed Remove some unnecessary parens in assert! conditions
While working on #122661, some of these started triggering our "unnecessary parens" lints due to a change in the `assert!` desugaring. A cursory search identified a few more. Some of these have been carried from before 1.0, were a bulk rename from the previous name of `assert!` left them in that state. I went and removed as many of these unnecessary parens as possible in order to have fewer annoyances in the future if we make the lint smarter.
2025-02-06 22:28:44 +00:00
DuskyElf
2431977ecf Rename and Move some UI tests to more suitable subdirs 2025-02-04 17:02:37 +05:30
bors
203e6c127c Auto merge of #133154 - estebank:issue-133137, r=wesleywiser
Reword resolve errors caused by likely missing crate in dep tree

Reword label and add `help`:

```
error[E0432]: unresolved import `some_novel_crate`
 --> f704.rs:1:5
  |
1 | use some_novel_crate::Type;
  |     ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
  |
  = help: if you wanted to use a crate named `some_novel_crate`, use `cargo add some_novel_crate` to add it to your `Cargo.toml`
```

Fix #133137.
2025-01-25 11:41:21 +00:00
Matthias Krüger
e96bb6ae1c
Rollup merge of #135926 - jieyouxu:needs-subprocess-thread, r=oli-obk
Implement `needs-subprocess` directive, and cleanup a bunch of tests to use `needs-{subprocess,threads}`

### Summary

Closes #128295.

- Implements `//@ needs-subprocess` directive in compiletest as requested in #128295. However, compiletest is a host tool, so we can't just try to spawn process because that spawns the process on *host*, not the *target*, under cross-compilation scenarios.
    - The short-term solution is to add *Yet Another* list of allow-list targets.
    - The long-term solution is to first check if a `$target` supports std, then try to run a binary to do run-time capability detection *on the target*. But that is tricky because you have to build-and-run a binary *for the target*.
    - This PR picks the short-term solution, because the long-term solution is highly non-trivial, and it's already an improvement over individual `ignore-*`s all over the place.
    - Opened an issue about the long-term solution in #135928.
- Documents `//@ needs-subprocess` in rustc-dev-guide.
- Replace `ignore-{wasm,wasm32,emscripten,sgx}` with `needs-{subprocess,threads}` where suitable in tests.
- Some drive-by test changes as I was trying to figure out if I could use `needs-{subprocess,threads}` and found some bits needlessly distracting.

Count of tests that use `ignore-{wasm,wasm32,emscripten,sgx}` before and after this PR:

| State | `ignore-sgx` | `ignore-wasm` | `ignore-emscripten` |
| - | - | - | - |
| Before this PR | 96 | 88 | 207 |
| After this PR | 36 | 38 | 61 |

<details>
<summary>Commands used to find out locally</summary>

```
--- before

[17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-sgx" tests | wc -l
96
[17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-wasm" tests | wc -l
88
[17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-emscripten" tests | wc -l
207

--- after

[17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-sgx" tests | wc -l
36
[17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-wasm" tests | wc -l
38
[17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-emscripten" tests | wc -l
61
```
</details>

### Review advice

- Best reviewed commit-by-commit.
- Non-trivial test changes (not mechanically simple replacements) are split into individual commits to help with review. Their individual commit messages give some basic description of the changes.
- I *could* split some test changes out into another PR, but I found that I needed to change some tests to `needs-threads`, some to `needs-subprocess`, and some needed to use *both*, so they might conflict and become very annoying.

---

r? ``@ghost`` (need to run try jobs)

try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: test-various
try-job: armhf-gnu
2025-01-24 16:25:43 +01:00
Esteban Küber
dd52bfc76e Reword "crate not found" resolve message
```
error[E0432]: unresolved import `some_novel_crate`
 --> file.rs:1:5
  |
1 | use some_novel_crate::Type;
  |     ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
```

On resolve errors where there might be a missing crate, mention `cargo add foo`:

```
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `nope`
  --> $DIR/conflicting-impl-with-err.rs:4:11
   |
LL | impl From<nope::Thing> for Error {
   |           ^^^^ use of unresolved module or unlinked crate `nope`
   |
   = help: if you wanted to use a crate named `nope`, use `cargo add nope` to add it to your `Cargo.toml`
```
2025-01-24 01:19:50 +00:00
许杰友 Jieyou Xu (Joe)
8a0310a0b1 tests: use needs-subprocess instead of ignore-{wasm32,emscripten,sgx} 2025-01-23 20:51:29 +08:00
Boxy
6833c27090 Bless and add tests 2025-01-23 06:01:36 +00:00
bors
a30f9151fe Auto merge of #135896 - matthiaskrgr:rollup-g6rv7za, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #132983 (Edit dangling pointers )
 - #135409 (Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block)
 - #135557 (Point at invalid utf-8 span on user's source code)
 - #135596 (Properly note when query stack is being cut off)
 - #135794 (Detect missing fields with default values and suggest `..`)
 - #135814 (ci: use ghcr buildkit image)
 - #135826 (Misc. `rustc_resolve` cleanups)
 - #135837 (Remove test panic from File::open)
 - #135856 (Library: Finalize dyn compatibility renaming)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-22 22:19:08 +00:00
Esteban Küber
57dd42d613 Point at invalid utf-8 span on user's source code
```
error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8
  --> $DIR/not-utf8-2.rs:6:5
   |
LL |     include!("not-utf8-bin-file.rs");
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: `[193]` is not valid utf-8
  --> $DIR/not-utf8-bin-file.rs:2:14
   |
LL |     let _ = "�|�␂!5�cc␕␂��";
   |              ^
   = note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
```

When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character.

Fix #76869.
2025-01-22 00:52:27 +00:00
Jorge Aparicio
ece8b0c94f make UI tests that use --test work on panic=abort targets
by adding `-Zpanic_abort_test`, which is a no-op on panic=unwind targets

fixes #135819
2025-01-21 17:39:15 +01:00
Oli Scherer
56178ddc90 Treat safe target_feature functions as unsafe by default 2025-01-15 08:58:17 +00:00
Oli Scherer
4a8773a3af Rename PatKind::Lit to Expr 2025-01-08 07:34:59 +00:00
Jubilee
7cf3b96a83
Rollup merge of #135046 - RalfJung:rustc_box_intrinsic, r=compiler-errors
turn rustc_box into an intrinsic

I am not entirely sure why this was made a special magic attribute, but an intrinsic seems like a more natural way to add magic expressions to the language.
2025-01-04 07:57:33 -08:00
Matthias Krüger
12cc9b4b6f
Rollup merge of #135044 - compiler-errors:better-infer-suggestions-in-const, r=oli-obk
Improve infer (`_`) suggestions in `const`s and `static`s

Fixes https://github.com/rust-lang/rust/issues/135010.

This PR does a few things to (imo) greatly improve the error message when users write something like `static FOO: [i32; _] = [1, 2, 3]`.

Firstly, it adapts the recovery code for when we encounter `_` in a const/static to work a bit more like `fn foo() -> _`, and removes the somewhat redundant query `diagnostic_only_typeck`.

Secondly, it changes the lowering for `[T; _]` to always lower under the `feature(generic_arg_infer)` logic to `ConstArgKind::Infer`. We still issue the feature error, so it's not doing anything *observable* on the good path, but it does mean that we no longer erroneously interpret `[T; _]`'s array length as a `_` **wildcard expression** (à la destructuring assignment, like `(_, y) = expr`).

Lastly it makes the suggestions verbose and fixes (well, suppresses) a bug with stashing and suggestions.

r? oli-obk
2025-01-03 22:12:45 +01:00
Ralf Jung
ac9cb908ac turn rustc_box into an intrinsic 2025-01-03 12:01:31 +01:00
Michael Goulet
0fd64efa2f Fix macro shenanigans 2025-01-02 23:39:17 +00:00
Michael Goulet
7601adb4a0 Make suggestion verbose and tweak error message 2025-01-02 23:39:17 +00:00
John Kåre Alsaker
4bf85c25ec Try to write the panic message with a single write_all call 2025-01-01 15:58:29 +01:00
许杰友 Jieyou Xu (Joe)
bc3e8917e3
Rollup merge of #134759 - Zalathar:normalize, r=jieyouxu
compiletest: Remove the `-test` suffix from normalize directives

This suffix was an artifact of using the same condition-checking engine as the `ignore-*` and `only-*` directives, but in practice we have only 2 tests that legitimately use a condition, and both of them only care about 32-bit vs 64-bit.

This PR detaches `normalize-*` directives from the condition checker, and replaces it with a much simpler system of four explicit `NormalizeKind` values. It then takes advantage of that simplicity to get rid of the `-test` suffix.

---

Addresses one of the points of #126372.

The new name-checking code is a bit quaint, but I think it's a definite improvement over the status quo.

---

The corresponding dev-guide update is https://github.com/rust-lang/rustc-dev-guide/pull/2172.

r? jieyouxu
2024-12-27 20:44:12 +08:00
Zalathar
835fbcbcab Remove the -test suffix from normalize directives 2024-12-27 19:58:16 +11:00
Jacob Pratt
b919afa70f
Rollup merge of #131522 - c410-f3r:unlock-rfc-2011, r=chenyukang
[macro_metavar_expr_concat] Fix #128346

Fix #128346
Fix #131393

The syntax is invalid in both issues so I guess that theoretically the compiler should have aborted early.

This PR tries to fix a local problem but let me know if there are better options.

cc `@petrochenkov` if you are interested
2024-12-26 21:56:47 -05:00
Esteban Küber
94812f1c8f Use E0665 for missing #[default] error
Use orphaned error code for the same error it belonged to before.

```
error[E0665]: `#[derive(Default)]` on enum with no `#[default]`
  --> $DIR/macros-nonfatal-errors.rs:42:10
   |
LL |   #[derive(Default)]
   |            ^^^^^^^
LL | / enum NoDeclaredDefault {
LL | |     Foo,
LL | |     Bar,
LL | | }
   | |_- this enum needs a unit variant marked with `#[default]`
   |
   = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)
help: make this unit variant default by placing `#[default]` on it
   |
LL |     #[default] Foo,
   |     ~~~~~~~~~~~~~~
help: make this unit variant default by placing `#[default]` on it
   |
LL |     #[default] Bar,
   |     ~~~~~~~~~~~~~~
```
2024-12-21 19:14:58 +00:00
Jonathan Dönszelmann
d50c0a5480
Add hir::Attribute 2024-12-15 19:18:46 +01:00
Michael Goulet
c605c84be8 Stabilize async closures 2024-12-13 00:04:56 +00:00
Caio
b661e98f09 Fix #128346 2024-12-01 19:10:44 -03:00
Eric Huss
6005d1c9f7 Update more 2024 tests to remove -Zunstable-options 2024-11-28 14:32:45 -08:00
Eric Huss
f94142b366 Update tests to use new proc-macro header 2024-11-27 07:18:25 -08:00
许杰友 Jieyou Xu (Joe)
95ff642797 tests: remove //@ pretty-expanded usages
Done with

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

and

```
sd '//@pretty-expanded.*\n' '' tests/ui/**/*.rs
```
2024-11-26 02:50:48 +08:00
许杰友 Jieyou Xu (Joe)
f7e3de36fc
Rollup merge of #132949 - clubby789:macro-rules-attr-derive, r=fmease
Add specific diagnostic for using macro_rules macro as attribute/derive

Fixes #132928
2024-11-23 20:19:53 +08:00
Eric Huss
31c9222639 Stabilize the 2024 edition 2024-11-22 11:12:15 -08:00
clubby789
4627db2a10 Diagnostic for using macro_rules macro as attr/derive 2024-11-22 16:49:10 +00:00
clubby789
8522140caa Add test for using macro_rules macro as attribute/derive 2024-11-12 14:05:42 +00:00
dianne
d7d6238b23 use backticks instead of single quotes when reporting "use of unstable library feature"
This is consistent with all other diagnostics I could find containing
features and enables the use of `DiagSymbolList` for generalizing
diagnostics for unstable library features to multiple features.
2024-11-03 13:55:52 -08:00
Eric Huss
37c3884152 Annotate input reference tests 2024-10-30 16:47:47 -07:00
Nicholas Nethercote
dd2b027d5d Tweak more warnings.
Much like the previous commit.

I think the removal of "the token" in each message is fine here. There
are many more error messages that mention tokens without saying "the
token" than those that do say it.
2024-10-28 14:20:28 +11:00