| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
By removing some of the over-indenting. AST pretty printing now looks
correct. HIR pretty printing is better, but still over-indents some.
|
|
`concat_idents` has been around unstably for a long time, but there is
now a better (but still unstable) way to join identifiers using
`${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves
a lot of the problems with `concat_idents` and is on a better track
toward stabilization, so there is no need to keep both versions around.
`concat_idents!` still has a lot of use in the ecosystem so deprecate it
before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
|
|
Extends the change from #139653, which was on expressions, to literals.
Fixes #140098.
|
|
Introduce and use specialized `//@ ignore-auxiliary` for test support files instead of using `//@ ignore-test`
### Summary
Add a semantically meaningful directive for ignoring test *auxiliary* files. This is for auxiliary files that *participate* in actual tests but should not be built by `compiletest` (i.e. these files are involved through `mod xxx;` or `include!()` or `#[path = "xxx"]`, etc.).
### Motivation
A specialized directive like `//@ ignore-auxiliary` makes it way easier to audit disabled tests via `//@ ignore-test`.
- These support files cannot use the canonical `auxiliary/` dir because they participate in module resolution or are included, or their relative paths can be important for test intention otherwise.
Follow-up to:
- #139705
- #139783
- #139740
See also discussions in:
- [#t-compiler > Directive name for non-test aux files?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Directive.20name.20for.20non-test.20aux.20files.3F/with/512773817)
- [#t-compiler > Handling disabled `//@ ignore-test` tests](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Handling.20disabled.20.60.2F.2F.40.20ignore-test.60.20tests/with/512005974)
- [#t-compiler/meetings > [steering] 2025-04-11 Dealing with disabled tests](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202025-04-11.20Dealing.20with.20disabled.20tests/with/511717981)
### Remarks on remaining unconditionally disabled tests under `tests/`
After this PR, against commit 79a272c6402, only **14** remaining test files are disabled through `//@ ignore-test`:
<details>
<summary>Remaining `//@ ignore-test` files under `tests/`</summary>
```
tests/debuginfo/drop-locations.rs
4://@ ignore-test (broken, see #128971)
tests/rustdoc/macro-document-private-duplicate.rs
1://@ ignore-test (fails spuriously, see issue #89228)
tests/rustdoc/inline_cross/assoc-const-equality.rs
3://@ ignore-test (FIXME: #125092)
tests/ui/match/issue-27021.rs
7://@ ignore-test (#54987)
tests/ui/match/issue-26996.rs
7://@ ignore-test (#54987)
tests/ui/issues/issue-49298.rs
9://@ ignore-test (#54987)
tests/ui/issues/issue-59756.rs
2://@ ignore-test (rustfix needs multiple suggestions)
tests/ui/precondition-checks/write.rs
5://@ ignore-test (unimplemented)
tests/ui/precondition-checks/read.rs
5://@ ignore-test (unimplemented)
tests/ui/precondition-checks/write_bytes.rs
5://@ ignore-test (unimplemented)
tests/ui/explicit-tail-calls/drop-order.rs
2://@ ignore-test: tail calls are not implemented in rustc_codegen_ssa yet, so this causes 🧊
tests/ui/panics/panic-short-backtrace-windows-x86_64.rs
3://@ ignore-test (#92000)
tests/ui/json/json-bom-plus-crlf-multifile-aux.rs
3://@ ignore-test Not a test. Used by other tests
tests/ui/traits/next-solver/object-soundness-requires-generalization.rs
2://@ ignore-test (see #114196)
```
</details>
Of these, most are either **unimplemented**, or **spurious**, or **known-broken**. The outstanding one is `tests/ui/json/json-bom-plus-crlf-multifile-aux.rs` which I did not want to touch in *this* PR -- that aux file has load-bearing BOM and carriage returns and byte offset matters. I think those test files that require special encoding / BOM probably are better off as `run-make` tests. See #139968 for that aux file.
### Review advice
- Best reviewed commit-by-commit.
- The directive name diverged from the most voted `//@ auxiliary` because I think that's easy to confuse with `//@ aux-{crate,dir}`.
r? compiler
|
|
|
|
Explicitly annotate edition for `unpretty=expanded` and `unpretty=hir` tests
These emit prelude imports which means they are always edition dependent and so running them with a different `--edition` will fail.
|
|
r=davidtwco,Urgau,traviscross
Stabilize `cfg_boolean_literals`
Closes #131204
`@rustbot` labels +T-lang +I-lang-nominated
This will end up conflicting with the test in #138293 so whichever doesn't land first will need updating
--
# Stabilization Report
## General design
### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
[RFC 3695](https://github.com/rust-lang/rfcs/pull/3695), none.
### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
None
### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
None
## Has a call-for-testing period been conducted? If so, what feedback was received?
Yes; only positive feedback was received.
## Implementation quality
### Summarize the major parts of the implementation and provide links into the code (or to PRs)
Implemented in [#131034](https://github.com/rust-lang/rust/pull/131034).
### Summarize existing test coverage of this feature
- [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/true-false.rs)
- [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/raw-true-false.rs)
- [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs)
- [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs)
- Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs`
- Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs`
### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
The above mentioned issue; it should not block as it interacts with another unstable feature.
### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
None
### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- `@clubby789` (RFC)
- `@Urgau` (Implementation in rustc)
### Which tools need to be adjusted to support this feature. Has this work been done?
`rustdoc`'s unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized.
## Type system and execution rules
### What updates are needed to the reference/specification? (link to PRs when they exist)
A few lines to be added to the reference for configuration predicates, specified in the RFC.
|
|
These emit prelude imports which means they are always edition dependent
|
|
nnethercote:rm-Nonterminal-and-TokenKind-Interpolated, r=petrochenkov
Remove `Nonterminal` and `TokenKind::Interpolated`
A third attempt at this; the first attempt was #96724 and the second was #114647.
r? `@ghost`
|
|
Suggest remove redundant `$()?` around `vis`
Resolves: #139480 .
|
|
Handle a negated literal in `eat_token_lit`.
Fixes #139495.
r? `@petrochenkov`
|
|
|
|
Fixes #139495.
|
|
|
|
|
|
Fixes #139445.
The additional errors aren't great but the first one is still good and
it's the most important, and imperfect errors are better than ICEing.
|
|
This can happen when invalid syntax is passed to a declarative macro. We
shouldn't be too strict about the token stream position once the parser
has rejected the invalid syntax.
Fixes #139248.
|
|
Add new `PatKind::Missing` variants
To avoid some ugly uses of `kw::Empty` when handling "missing" patterns, e.g. in bare fn tys. Helps with #137978. Details in the individual commits.
r? ``@oli-obk``
|
|
Apply `Recovery::Forbidden` when reparsing pasted macro fragments.
Fixes #137874.
The changes to the output of `tests/ui/associated-consts/issue-93835.rs`
partly undo the changes seen when `NtTy` was removed in #133436, which
is good.
r? ``@petrochenkov``
|
|
Fixes #137874.
Removes `tests/crashes/137874.rs`; the new test is simpler (defines its
own macro) but tests the same thing.
The changes to the output of `tests/ui/associated-consts/issue-93835.rs`
partly undo the changes seen when `NtTy` was removed in #133436, which
is good.
|
|
|
|
|
|
They are no longer needed.
This does slightly worsen the error message for a single test, but that
test contains code that is so badly broken that I'm not worried about
it.
|
|
`NtBlock` is the last remaining variant of `Nonterminal`, so once it is
gone then `Nonterminal` can be removed as well.
|
|
Notes about tests:
- tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are
now duplicated due to repeated parsing.
- tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto.
- `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large
but the only difference is the insertion of a single
invisible-delimited group around a metavar.
- `tests/ui/attributes/nonterminal-expansion.rs`: a slight span
degradation, somehow related to the recent massive attr parsing
rewrite (#135726). I couldn't work out exactly what is going wrong,
but I don't think it's worth holding things up for a single slightly
suboptimal error message.
|
|
"Missing" patterns are possible in bare fn types (`fn f(u32)`) and
similar places. Currently these are represented in the AST with
`ast::PatKind::Ident` with no `by_ref`, no `mut`, an empty ident, and no
sub-pattern. This flows through to `{hir,thir}::PatKind::Binding` for
HIR and THIR.
This is a bit nasty. It's very non-obvious, and easy to forget to check
for the exceptional empty identifier case.
This commit adds a new variant, `PatKind::Missing`, to do it properly.
The process I followed:
- Add a `Missing` variant to `{ast,hir,thir}::PatKind`.
- Chang `parse_param_general` to produce `ast::PatKind::Missing`
instead of `ast::PatKind::Missing`.
- Look through `kw::Empty` occurrences to find functions where an
existing empty ident check needs replacing with a `PatKind::Missing`
check: `print_param`, `check_trait_item`, `is_named_param`.
- Add a `PatKind::Missing => unreachable!(),` arm to every exhaustive
match identified by the compiler.
- Find which arms are actually reachable by running the test suite,
changing them to something appropriate, usually by looking at what
would happen to a `PatKind::Ident`/`PatKind::Binding` with no ref, no
`mut`, an empty ident, and no subpattern.
Quite a few of the `unreachable!()` arms were never reached. This makes
sense because `PatKind::Missing` can't happen in every pattern, only
in places like bare fn tys and trait fn decls.
I also tried an alternative approach: modifying `ast::Param::pat` to
hold an `Option<P<Pat>>` instead of a `P<Pat>`, but that quickly turned
into a very large and painful change. Adding `PatKind::Missing` is much
easier.
|
|
|
|
This removes E0773 "A builtin-macro was defined more than once."
|
|
For macros that are implemented on the compiler, we do *not* mention the `-Zmacro-backtrace` flag. This includes `derive`s and standard macros.
|
|
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
|
|
Remove `NtItem` and `NtStmt`
Another piece of #124141.
r? `@petrochenkov`
|
|
|
|
|
|
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).
|
|
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.
|
|
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.
|
|
|
|
|
|
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.
|
|
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.
|
|
We now use invisible delimiters for expanded `vis` fragments, instead of
`Token::Interpolated`.
|
|
|
|
|
|
```
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;
|
```
|
|
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.
|
|
|
|
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.
|
|
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
|
|
```
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`
```
|
