Limit the recursion depth, as each level of nesting adds another deeper
projection.
There might be a more complex way of handling the problem, but infinite
recursions are bad, and don't allow Clippy to terminate properly.
changelog: [`significant_drop_tightening`]: do not recurse forever when
checking for attribute on type or its constituent
Fixesrust-lang/rust-clippy#13544
@rustbot label +L-nursery
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)
when compiling target LLVM with `opt-dist local` on Windows/MinGW,
profraw files are being compressed with zlib, so compiling without it
will make `llvm-profdata` complain about lacking of zlib support. this
error is shown:
`profile uses zlib compression but the profile reader was built without
zlib support`
example from llvm test suite: 76b5fcbf97/llvm/test/tools/llvm-profdata/nocompress.test (L15)
`bl!` is being used to add a leading underscore on Apple targets.
`asm_sym` has been around since 2022 and handles platform-specific
symbol names automatically, so make use of this instead.
I have verified that `armv7s-apple-ios` still builds correctly.
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
git: ignore `60600a6fa4` for blame purposes
60600a6fa4 was simply breaking up compiletest's `runtest.rs` and isn't very useful in git blame.
r? `@onur-ozkan`
Move eager translation to a method on Diag
This will allow us to eagerly translate messages on a top-level diagnostic, such as a `LintDiagnostic`. As a bonus, we can remove the awkward closure passed into Subdiagnostic and make better use of `Into`.
r? `@nnethercote`
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.
Consistent with treating Ctor Call as Struct in liveness analysis
Fixes#139627
When `ExprKind::Call` is a `Ctor`, skips the checking of `expr` and only checks the arguments, thus being consistent with `ExprKind::Struct`.
r? compiler
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.
- Do not replace macro results in then/else branches
- Extract condition snippet from the right context
- Make suggestion `MaybeIncorrect` if it would lead to losing comments
changelog: [`bool_to_int_with_if`]: properly handle macros
Fixesrust-lang/rust-clippy#14628
This will allow us to eagerly translate messages on a top-level
diagnostic, such as a `LintDiagnostic`. As a bonus, we can remove the
awkward closure passed into Subdiagnostic and make better use of
`Into`.
Instead of looking for angle brackets in the source code, use the HIR
and Ty interfaces to either copy the original type, or complete it with
`_` placeholders if all type and const generic arguments are inferred.
Fixesrust-lang/rust-clippy#14581
changelog: [`from_iter_instead_of_collect`]: show correct type in
suggestion
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.
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.
This shows places where the use of `name_or_empty` causes problems, i.e.
we print empty identifiers in error messages:
```
error: unrecognized field name ``
error: `` isn't a valid `#[macro_export]` argument
`#[no_sanitize()]` should be applied to a function
```
(The last one is about an attribute `#[no_sanitize("address")]`.)
The next commit will fix these.
