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`
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()]`](6d71251cf9/tests/ui/cfg/true-false.rs)
- [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](6d71251cf9/tests/ui/cfg/raw-true-false.rs)
- [Interaction with the unstable `#[doc(cfg(..))]` feature](6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs)
- [Denying `--check-cfg=cfg(true/false)`](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.
* 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
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.
Apparently there are tests that print canonical paths *and* tests which
print non-canonical paths.
An example of the latter is `tests/ui/type_length_limit.rs`.
Fix fixes failures of the following tests when build directory is a
symlink:
- `tests/ui/error-codes/E{0464,0523}.rs`
- `tests/ui/crate-loading/crateresolve{1,2}.rs` (those are the same tests)
Overhaul `AssocItem`
`AssocItem` has multiple fields that only make sense some of the time. E.g. the `name` can be empty if it's an RPITIT associated type. It's clearer and less error prone if these fields are moved to the relevant `kind` variants.
r? ``@fee1-dead``
To accurately reflect that RPITIT assoc items don't have a name. This
avoids the use of `kw::Empty` to mean "no name", which is error prone.
Helps with #137978.
