Remove `token::{Open,Close}Delim`
By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`.
PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by
replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless
variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing
with delimiters. It also makes `ast::TokenKind` more similar to
`parser::TokenType`.
This requires a few new methods:
- `TokenKind::is_{,open_,close_}delim()` replace various kinds of
pattern matches.
- `Delimiter::as_{open,close}_token_kind` are used to convert
`Delimiter` values to `TokenKind`.
Despite these additions, it's a net reduction in lines of code. This is
because e.g. `token::OpenParen` is so much shorter than
`token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms
reduce to single line forms. And many places where the number of lines
doesn't change are still easier to read, just because the names are
shorter, e.g.:
```
- } else if self.token != token::CloseDelim(Delimiter::Brace) {
+ } else if self.token != token::CloseBrace {
```
r? `@petrochenkov`
jsondocck: Require command is at start of line
In one place we use `///``@``` instead of `//``@`.`` The test-runner allowed it, but it probably shouldn't. Ran into by ``@lolbinarycat`` in https://github.com/rust-lang/rust/pull/132748#issuecomment-2816469322:
```
error: unknown disambiguator `?(`
##[error] --> /checkout/tests/rustdoc-json/fns/return_type_alias.rs:3:25
|
3 | ///@ set foo = "$.index[?(``@.name=='Foo')].id"``
| ^^
|
```
Maybe it's also worth erroring on this like we added in #137103
r? ``@GuillaumeGomez``
Use `output_base_dir` for `mir_dump_dir`
It just occurred to me that the problem might be due to multiple revisions using the same dump directory (and therefore deleting the other revision's dir). This fixes that by simply using the normal per-test output directory, which is revision safe.
By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`.
PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by
replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless
variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing
with delimiters. It also makes `ast::TokenKind` more similar to
`parser::TokenType`.
This requires a few new methods:
- `TokenKind::is_{,open_,close_}delim()` replace various kinds of
pattern matches.
- `Delimiter::as_{open,close}_token_kind` are used to convert
`Delimiter` values to `TokenKind`.
Despite these additions, it's a net reduction in lines of code. This is
because e.g. `token::OpenParen` is so much shorter than
`token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms
reduce to single line forms. And many places where the number of lines
doesn't change are still easier to read, just because the names are
shorter, e.g.:
```
- } else if self.token != token::CloseDelim(Delimiter::Brace) {
+ } else if self.token != token::CloseBrace {
```
simd intrinsics with mask: accept unsigned integer masks, and fix some of the errors
It's not clear at all why the mask would have to be signed, it is anyway interpreted bitwise. The backend should just make sure that works no matter the surface-level type; our LLVM backend already does this correctly. The note of "the mask may be widened, which only has the correct behavior for signed integers" explains... nothing? Why can't the code do the widening correctly? If necessary, just cast to the signed type first...
Also while we are at it, fix the errors. For simd_masked_load/store, the errors talked about the "third argument" but they meant the first argument (the mask is the first argument there). They also used the wrong type for `expected_element`.
I have extremely low confidence in the GCC part of this PR.
See [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/On.20the.20sign.20of.20masks)
Do not remove trivial `SwitchInt` in analysis MIR
This PR ensures that we don't prematurely remove trivial `SwitchInt` terminators which affects both the borrow-checking and runtime semantics (i.e. UB) of the code. Previously the `SimplifyCfg` optimization was removing `SwitchInt` terminators when they was "trivial", i.e. when all arms branched to the same basic block, even if that `SwitchInt` terminator had the side-effect of reading an operand which (for example) may not be initialized or may point to an invalid place in memory.
This behavior is unlike all other optimizations, which are only applied after "analysis" (i.e. borrow-checking) is finished, and which Miri disables to make sure the compiler doesn't silently remove UB.
Fixing this code "breaks" (i.e. unmasks) code that used to borrow-check but no longer does, like:
```rust
fn foo() {
let x;
let (0 | _) = x;
}
```
This match expression should perform a read because `_` does not shadow the `0` literal pattern, and the compiler should have to read the match scrutinee to compare it to 0. I've checked that this behavior does not actually manifest in practice via a crater run which came back clean: https://github.com/rust-lang/rust/pull/139042#issuecomment-2767436367
As a side-note, it may be tempting to suggest that this is actually a good thing or that we should preserve this behavior. If we wanted to make this work (i.e. trivially optimize out reads from matches that are redundant like `0 | _`), then we should be enabling this behavior *after* fixing this. However, I think it's kinda unprincipled, and for example other variations of the code don't even work today, e.g.:
```rust
fn foo() {
let x;
let (0.. | _) = x;
}
```
Clean UI tests 4 of n
Cleaned up some tests that have `issue` in the title. I kept the commits to be one per "`issue`" cleanup/rename to make it easier to check. I can rebase to one commit once the changes are approved.
Related Issues:
#73494#133895
r? jieyouxu
Rewrite on_unimplemented format string parser.
This PR rewrites the format string parser for `rustc_on_unimplemented` and `diagnostic::on_unimplemented`. I plan on moving this code (and more) into the new attribute parsing system soon and wanted to PR it separately.
This PR introduces some minor differences though:
- `rustc_on_unimplemented` on trait *implementations* is no longer checked/used - this is actually never used (outside of some tests) so I plan on removing it in the future.
- for `rustc_on_unimplemented`, it introduces the `{This}` argument in favor of `{ThisTraitname}` (to be removed later). It'll be easier to parse.
- for `rustc_on_unimplemented`, `Self` can now consistently be used as a filter, rather than just `_Self`. It used to not match correctly on for example `Self = "[{integer}]"`
- Some error messages now have better spans.
Fixes https://github.com/rust-lang/rust/issues/130627
Deduplicate & clean up Nix shell
1. Deduplicate the flake and shell files
2. Remove flake-utils
3. Remove `with` statements
They are considered bad practice nowadays because the slow down the evalulator and have weird shadowing rules.
4. Use `env`
:3
5. use `callPackage`
It's the recommended way for derivations like these.
6. Use `packages` in the shell
There is no reason to use `buildInputs` for a mkShell (except in funny cases that will not be seen here), so the `packages` attr is recommended now days.
r? WaffleLapkin
run-make: drop `os_pipe` workaround now that `anonymous_pipe` is stable on beta
Follow-up to #137537 where I had to include a temporary dep on `os_pipe` before `anonymous_pipe` was stabilized. Now that `anonymous_pipe` is stable on beta, we can get rid of this workaround.
Closes#137532. (Final cleanup item)
r? `@Kobzol`
sync::mpsc: prevent double free on `Drop`
This PR is fixing a regression introduced by #121646 that can lead to a double free when dropping the channel.
The details of the bug can be found in the corresponding crossbeam PR https://github.com/crossbeam-rs/crossbeam/pull/1187
rustdoc-json: Output target feature information
`#[target_feature]` attributes refer to a target-specific list of features. Enabling certain features can imply enabling other features. Certain features are always enabled on certain targets, since they are required by the target's ABI. Features can also be enabled indirectly based on other compiler flags.
Feature information is ultimately known to `rustc`. Rather than force external tools to track it – which may be wildly impractical due to `-C target-cpu` – have `rustdoc` output `rustc`'s feature data.
This change is motivated by https://github.com/obi1kenobi/cargo-semver-checks/issues/1246, which intends to detect semver hazards caused by `#[target_feature]`.
try-job: aarch64-gnu
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: aarch64-apple
deref patterns: implement implicit deref patterns
This implements implicit deref patterns (per https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Implicit-deref-patterns) and adds tests and an unstable book chapter.
Best reviewed commit-by-commit. Overall there's a lot of additions, but a lot of that is tests, documentation, and simple(?) refactoring.
Tracking issue: #87121
r? ``@Nadrieril``
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 79a272c640, 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
f*::NAN: guarantee that this is a quiet NaN
I think we should guarantee that this is a quiet NaN. This then implies that programs not using `f*::from_bits` (or unsafe type conversions) are guaranteed to only work with quiet NaNs. It would be awkward if people start to write `0.0 / 0.0` instead of using the constant just because they want to get a guaranteed-quiet NaN.
This is a `@rust-lang/libs-api` change. The definition of this constant currently is `0.0 / 0.0`, which is already guaranteed to be a quiet NaN. So all this does is forward that guarantee to our users.
opt-dist: add a flag for running tests
when using `opt-dist local` user probably won't need to run tests (for various reasons). currently the only way to disable them is to set `TRY_DIST_BUILD=1`, which is not obvious and can be bad for non-CI envronments (as I guess)
possibly the `run_tests` name can be confusing too...
r? Kobzol
try-job: dist-x86_64-linux
try-job: dist-x86_64-msvc
This is for 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.).
A specialized directive like `//@ ignore-auxiliary` makes it way easier
to audit disabled tests via `//@ ignore-test`.
when using `opt-dist local` user probably won't need to run tests (for
various reasons). currently the only way to disable them is to set
`TRY_DIST_BUILD=1`, which is not obvious and can be bad for non-CI
envronments (as I guess)
Update cargo
4 commits in 864f74d4eadcaea3eeda37a2e7f4d34de233d51e..d811228b14ae2707323f37346aee3f4147e247e6
2025-04-11 20:37:27 +0000 to 2025-04-15 15:18:42 +0000
- use `zlib-rs` for gzip compression in rust code (rust-lang/cargo#15417)
- test(rustfix): Use `snapbox` for snapshot testing (rust-lang/cargo#15429)
- chore(deps): update rust crate gix to 0.71.0 [security] (rust-lang/cargo#15391)
- Make sure search paths inside OUT_DIR precede external paths (rust-lang/cargo#15221)
Also,
* The license exception of sha1_smol with BSD-3-Clause is no longer needed, as `gix-*` doesn't depend on it.
* Cargo depends on zlib-rs, which is distributed under Zlib license
r? ghost
Rollup of 9 pull requests
Successful merges:
- #135340 (Add `explicit_extern_abis` Feature and Enforce Explicit ABIs)
- #139440 (rustc_target: RISC-V: feature addition batch 2)
- #139667 (cfi: Remove #[no_sanitize(cfi)] for extern weak functions)
- #139828 (Don't require rigid alias's trait to hold)
- #139854 (Improve parse errors for stray lifetimes in type position)
- #139889 (Clean UI tests 3 of n)
- #139894 (Fix `opt-dist` CLI flag and make it work without LLD)
- #139900 (stepping into impls for normalization is unproductive)
- #139915 (replace some #[rustc_intrinsic] usage with use of the libcore declarations)
r? `@ghost`
`@rustbot` modify labels: rollup
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.
I'm removing empty identifiers everywhere, because in practice they
always mean "no identifier" rather than "empty identifier". (An empty
identifier is impossible.) It's better to use `Option` to mean "no
identifier" because you then can't forget about the "no identifier"
possibility.
Some specifics:
- When testing an attribute for a single name, the commit uses the
`has_name` method.
- When testing an attribute for multiple names, the commit uses the new
`has_any_name` method.
- When using `match` on an attribute, the match arms now have `Some` on
them.
In the tests, we now avoid printing empty identifiers by not printing
the identifier in the `error:` line at all, instead letting the carets
point out the problem.
* The license exception of sha1_smol with BSD-3-Clause is no longer
needed, as `gix-*` doesn't depend on it.
* Cargo depends on zlib-rs, which is distributed under Zlib license
Rename `LifetimeName` as `LifetimeKind`.
It's a much better name, more consistent with how we name such things.
Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this field used to have the type `LifetimeRes` and then the type was changed but the field name remained the same.
r? ``@BoxyUwU``
Update books
## rust-lang/book
1 commits in 45f05367360f033f89235eacbbb54e8d73ce6b70..d33916341d480caede1d0ae57cbeae23aab23e88
2025-04-08 18:24:27 UTC to 2025-04-08 18:24:27 UTC
- Ch01+ch02 after tech review (rust-lang/book#4329)
## rust-lang/edition-guide
2 commits in 1e27e5e6d5133ae4612f5cc195c15fc8d51b1c9c..467f45637b73ec6aa70fb36bc3054bb50b8967ea
2025-04-15 19:49:59 UTC to 2025-04-11 15:27:31 UTC
- fix grammar errors (rust-lang/edition-guide#374)
- remove the unused and deprecated `multilingual` field from `book.toml` (rust-lang/edition-guide#375)
## rust-lang/nomicon
2 commits in b4448fa406a6dccde62d1e2f34f70fc51814cdcc..0c10c30cc54736c5c194ce98c50e2de84eeb6e79
2025-04-09 01:54:42 UTC to 2025-04-07 20:22:31 UTC
- Remove double wording in opaque type chapter (rust-lang/nomicon#487)
- remove `rust-intrinsic` ABI (rust-lang/nomicon#485)
## rust-lang/reference
6 commits in 46435cd4eba11b66acaa42c01da5c80ad88aee4b..3340922df189bddcbaad17dc3927d51a76bcd5ed
2025-04-15 19:03:24 UTC to 2025-04-10 01:56:25 UTC
- Add a new grammar renderer (rust-lang/reference#1787)
- Misc. spelling fixes (rust-lang/reference#1785)
- Fix std::ops links in range-expr (rust-lang/reference#1786)
- traits.md: remove unusual formatting (rust-lang/reference#1784)
- doc: add missing space (rust-lang/reference#1782)
- spelling fix, Discrimants -> Discriminants (rust-lang/reference#1783)
Fix some tidy paper cuts
The main thing this fixes is that currently, if you run `x t tidy` it will format ~6K files, even though it's supposed to format only modified files (whatever this is a useful optimization or not is besides the point). The problem is that `x t tidy` never writes the `rustfmt` stamp, so it always assumes `rustfmt` that was last used is outdated and we need to recheck everything. This PR fixes it by actually writing the stamp.
There are also some minor tweaks to comments/diagnostics. cc ```@Kobzol``` this probably conflicts with #138591. I didn't fix anything, just tried to document better the status quo.
r? ```@jieyouxu```
Fix some bootstrap papercuts
... related to jj and my `./build` symlink setup[^1].
I'm not sure if these are good solutions, but they seem to work. See commits for a bit more info.
r? ``@jieyouxu``
[^1]: see #139804
Philipp Krones