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
support config extensions
_Copied from the `rustc-dev-guide` addition:_
>When working on different tasks, you might need to switch between different bootstrap >configurations.
>Sometimes you may want to keep an old configuration for future use. But saving raw config >values in
>random files and manually copying and pasting them can quickly become messy, especially if >you have a
>long history of different configurations.
>
>To simplify managing multiple configurations, you can create config extensions.
>
>For example, you can create a simple config file named `cross.toml`:
>
>```toml
>[build]
>build = "x86_64-unknown-linux-gnu"
>host = ["i686-unknown-linux-gnu"]
>target = ["i686-unknown-linux-gnu"]
>
>
>[llvm]
>download-ci-llvm = false
>
>[target.x86_64-unknown-linux-gnu]
>llvm-config = "/path/to/llvm-19/bin/llvm-config"
>```
>
>Then, include this in your `bootstrap.toml`:
>
>```toml
>include = ["cross.toml"]
>```
>
>You can also include extensions within extensions recursively.
>
>**Note:** In the `include` field, the overriding logic follows a right-to-left order. For example,
in `include = ["a.toml", "b.toml"]`, extension `b.toml` overrides `a.toml`. Also, parent extensions
always overrides the inner ones.
try-job: x86_64-mingw-2
Implement `pin!()` using `super let`
Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076
This uses `super let` to implement `pin!()`.
This means we can remove [the hack](https://github.com/rust-lang/rust/pull/138717) we had to put in to fix https://github.com/rust-lang/rust/issues/138596.
It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.
While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.
It'd help [the experiment](https://github.com/rust-lang/rust/issues/139076) to have `pin!()` use `super let`, so we can get some more experience with it.
Rollup of 8 pull requests
Successful merges:
- #139351 (Autodiff batching2)
- #139483 (f*::NAN: guarantee that this is a quiet NaN)
- #139498 (Ignore zero-sized types in wasm future-compat warning)
- #139967 (Introduce and use specialized `//@ ignore-auxiliary` for test support files instead of using `//@ ignore-test`)
- #139969 (update libc)
- #139971 (Make C string merging test work on MIPS)
- #139974 (Change `InterpCx::instantiate*` function visibility to pub)
- #139977 (Fix drop handling in `hint::select_unpredictable`)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix drop handling in `hint::select_unpredictable`
This intrinsic doesn't drop the value that is not selected so this is manually done in the public function that wraps the intrinsic.
Change `InterpCx::instantiate*` function visibility to pub
For some ongoing work in Miri we need to be able to access `instantiate_from_current_frame_and_normalize_erasing_regions` and `instantiate_from_frame_and_normalize_erasing_regions` on `InterpCx`.
r? `@RalfJung`
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
Ignore zero-sized types in wasm future-compat warning
This commit fixes a false positive of the warning triggered for #138762 and the fix is to codify that zero-sized types are "safe" in both the old and new ABIs.
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.
Autodiff batching2
~I will rebase it once my first PR landed.~ done.
This autodiff batch mode is more similar to scalar autodiff, since it still only takes one shadow argument.
However, that argument is supposed to be `width` times larger.
r? `@oli-obk`
Tracking:
- https://github.com/rust-lang/rust/issues/124509
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 `60600a6fa403216bfd66e04f948b1822f6450af7` for blame purposes
60600a6fa403216bfd66e04f948b1822f6450af7 was simply breaking up compiletest's `runtest.rs` and isn't very useful in git blame.
r? `@onur-ozkan`
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](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.
replace some #[rustc_intrinsic] usage with use of the libcore declarations
Better to centralize the `#[rustc_intrinsic]` declarations in libcore than have them spread across the test suite as well.
stepping into impls for normalization is unproductive
See the inline comment. This builds on the reasoning from #136824 (https://gist.github.com/lcnr/c49d887bbd34f5d05c36d1cf7a1bf5a5). Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/176.
Looking at the end of the gist:
> The only ways to project out of a constructor are the following:
> - accessing an associated item, either its type or its item bounds
> - accessing super predicates
Detecting cases where we accessing the type of an associated item is easy, it's simply when we normalize. I don't yet know how to detect whether we step out of an impl by accessing item bounds. Once we also detect these cases we should be able to soundly support arbitrary coinductive traits. Luckily this does not matter for this PR :>
r? `@compiler-errors` cc `@nikomatsakis`
Clean UI tests 3 of n
Cleaned up 2 tests in `tests/ui/numbers-arithemetic` to be more useful. One for each commit. I can squash these into one commit when approved.
Related Issues:
#73494#133895
r? jieyouxu
Improve parse errors for stray lifetimes in type position
While technically & syntactically speaking lifetimes do begin[^1] types in type contexts (this essentially excludes generic argument lists) and require a following `+` to form a complete type (`'a +` denotes a bare trait object type), the likelihood that a user meant to write a lifetime-prefixed bare trait object type in *modern* editions (Rust ≥2021) when placing a lifetime into a type context is incredibly low (they would need to add at least three tokens to turn it into a *semantically* well-formed TOT: `'a` → `dyn 'a + Trait`).
Therefore let's *lie* in modern editions (just like in PR https://github.com/rust-lang/rust/pull/131239, a precedent if you will) by stating "*expected type, found lifetime*" in such cases which is a lot more a approachable, digestible and friendly compared to "*lifetime in trait object type must be followed by `+`*" (as added in PR https://github.com/rust-lang/rust/pull/69760).
I've also added recovery for "ampersand-less" reference types (e.g., `'a ()`, `'a mut Ty`) in modern editions because it was trivial to do and I think it's not unlikely to occur in practice.
Fixes#133413.
[^1]: For example, in the context of decl macros, this implies that a lone `'a` always matches syntax fragment `ty` ("even if" there's a later macro matcher expecting syntax fragment `lifetime`). Rephrased, lifetimes (in type contexts) *commit* to the type parser.
Don't require rigid alias's trait to hold
See test for write-up. TL;DR is that we don't need the trait bound to hold, since we enforce it during WF.
I think this is preferable to introducing (if we even could do so) a more specific hack around coroutine interiors, higher ranked types, etc, since this is just a manifestation of more pervasive issues w/ lifetime erasure in coroutines. This just doesn't manifest in the old solver b/c it doesn't try to prove `T: Trait` holds when rigidly projecting `<T as Trait>::Assoc`.
It's pretty clear that this affects quite a few traits (https://github.com/rust-lang/rust/pull/139763), so I think this needs fixing.
r? lcnr
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/177
Add `explicit_extern_abis` Feature and Enforce Explicit ABIs
The unstable `explicit_extern_abis` feature is introduced, requiring explicit ABIs in `extern` blocks. Hard errors will be enforced with this feature enabled in a future edition.
RFC rust-lang/rfcs#3722
Update #134986
fix for multiple `#[repr(align(N))]` on functions
tracking issue: https://github.com/rust-lang/rust/issues/82232
fixes https://github.com/rust-lang/rust/issues/132464
The behavior of align is specified at https://doc.rust-lang.org/reference/type-layout.html#r-layout.repr.alignment.align
> For align, if the specified alignment is less than the alignment of the type without the align modifier, then the alignment is unaffected.
So in effect that means that the maximum of the specified alignments should be chosen. That is also the current behavior for `align` on ADTs:
```rust
#![feature(fn_align)]
#[repr(C, align(32), align(64))]
struct Foo {
x: u64,
}
const _: () = assert!(core::mem::align_of::<Foo>() == 64);
// See the godbolt LLVM output: the alignment of this function is 32
#[no_mangle]
#[repr(align(32))]
#[repr(align(64))]
fn foo() {}
// The current logic just picks the first alignment: the alignment of this function is 64
#[no_mangle]
#[repr(align(64))]
#[repr(align(32))]
fn bar() {}
```
https://godbolt.org/z/scco435jEafa859f812/compiler/rustc_middle/src/ty/mod.rs (L1529-L1532)
The https://github.com/rust-lang/rust/issues/132464 issue is really about parsing/representing the attribute, which has already been improved and now uses the "parse, don't validate" attribute approach. That means the behavior is already different from what the issue describes: on current `main`, the first value is chosen. This PR fixes a logic error, where we just did not check for the effect of two or more `align` modifiers. In combination, that fixes the issue.
cc ``@jdonszelmann`` if you do have further thoughs here
parser: Remove old diagnostic notes for type ascription syntax
Type ascription syntax was removed by #109128 in 2023, so “remove this again in a few months” is long overdue.
Happily, this also reduces the amount of parser diagnostic code that cares whether the compiler is unstable.
---
See also the recent #138898, which removed some other related dead code but declined to touch the diagnostics.
It's possible that some of these parser tests are no longer useful at all, but I haven't investigated them for this PR.
Include optional dso_local marker for functions in `enum-match.rs`
This PR adds the `dso_local` marker to the `enum-match.rs` test annotations for all the `match\d+` functions. These markers are added by LLVM when targeting `aarch64-unknown-none` even though they are missing in `aarch64-unknown-linux-gnu`. This is causing a CI error when running the codegen suite on the `aarch64-unknown-none` target for ferrocene.
r? ``@scottmcm``
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``
Fix `register_group_alias` for tools
In clippy we're looking at renaming `clippy::all` and registering an alias for it but currently that doesn't work for tools
The `lint_ids` of the alias are now populated at the time of registration to make it easier to handle
Use a session counter to make anon dep nodes unique
This changes the unique session hash used to ensure unique anon dep nodes per session from a timestamp to a counter.
This is nicer for debugging as it makes the dep graph deterministic.
hygiene: Rename semi-transparent to semi-opaque
"Semi-transparent" is just too damn long for a name, especially when used multiple times on a single line, it bothered me when working on #139083.
An optimist sees a macro as semi-opaque, a pessimist sees it as semi-transparent.
Or is it the other way round?
Add minimal x86_64-lynx-lynxos178 support.
Add minimal x86_64-lynx-lynxos178 support. It's possible to build no_std
programs with this compiler.
## Tier 3 Target Policy
> A tier 3 target must have a designated developer or developers (the "target
maintainers") on record to be CCed when issues arise regarding the target. (The
mechanism to track and CC such developers may evolve over time.)
Tim Newsome (`@tnewsome-lynx)` will be the designated developer for
x86_64-lynx-lynxos178 support.
> Targets must use naming consistent with any existing targets; for instance, a
target for the same CPU or OS as an existing Rust target should use the same
name for that CPU or OS. Targets should normally use the same names and naming
conventions as used elsewhere in the broader ecosystem beyond Rust (such as in
other toolchains), unless they have a very good reason to diverge. Changing the
name of a target can be highly disruptive, especially once the target reaches a
higher tier, so getting the name right is important even for a tier 3 target.
I believe the target is named appropriately.
> Target names should not introduce undue confusion or ambiguity unless
absolutely necessary to maintain ecosystem compatibility. For example, if the
name of the target makes people extremely likely to form incorrect beliefs about
what it targets, the name should be changed or augmented to disambiguate it.
The target name is not confusing.
> If possible, use only letters, numbers, dashes and underscores for the name.
Periods (.) are known to cause issues in Cargo.
Done.
> Tier 3 targets may have unusual requirements to build or use, but must not
create legal issues or impose onerous legal terms for the Rust project or for
Rust developers or users.
> The target must not introduce license incompatibilities.
> Anything added to the Rust repository must be under the standard Rust license
(MIT OR Apache-2.0).
All this new code is licensed under the Apache-2.0 license.
> The target must not cause the Rust tools or libraries built for any other host
(even when supporting cross-compilation to the target) to depend on any new
dependency less permissive than the Rust licensing policy. This applies whether
the dependency is a Rust crate that would require adding new license exceptions
(as specified by the tidy tool in the rust-lang/rust repository), or whether the
dependency is a native library or binary. In other words, the introduction of
the target must not cause a user installing or running a version of Rust or the
Rust tools to be subject to any new license requirements.
Done.
> Compiling, linking, and emitting functional binaries, libraries, or other code
for the target (whether hosted on the target itself or cross-compiling from
another target) must not depend on proprietary (non-FOSS) libraries. Host tools
built for the target itself may depend on the ordinary runtime libraries
supplied by the platform and commonly used by other applications built for the
target, but those libraries must not be required for code generation for the
target; cross-compilation to the target must not require such libraries at all.
For instance, rustc built for the target may depend on a common proprietary C
runtime library or console output library, but must not depend on a proprietary
code generation library or code optimization library. Rust's license permits
such combinations, but the Rust project has no interest in maintaining such
combinations within the scope of Rust itself, even at tier 3.
I think we're in the clear here. We do link against some static libraries that
are proprietary (like libm and libc), but those are not used to generate code.
E.g. the VxWorks target requires `wr-c++` to be installed, which is not
publically available.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous"
legal/licensing terms include but are not limited to: non-disclosure
requirements, non-compete requirements, contributor license agreements (CLAs) or
equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional
on the employer or employment of any particular Rust developers, revocable
terms, any requirements that create liability for the Rust project or its
developers or users, or any requirements that adversely affect the livelihood or
prospects of the Rust project or its developers or users.
Our intention is to allow anyone with access to LynxOS CDK to use Rust for it.
> Neither this policy nor any decisions made regarding targets shall create any
binding agreement or estoppel by any party. If any member of an approving Rust
team serves as one of the maintainers of a target, or has any legal or
employment requirement (explicit or implicit) that might affect their decisions
regarding a target, they must recuse themselves from any approval decisions
regarding the target's tier status, though they may otherwise participate in
discussions.
> This requirement does not prevent part or all of this policy from being cited
in an explicit contract or work agreement (e.g. to implement or maintain support
for a target). This requirement exists to ensure that a developer or team
responsible for reviewing and approving a target does not face any legal threats
or obligations that would prevent them from freely exercising their judgment in
such approval, even if such judgment involves subjective matters or goes beyond
the letter of these requirements.
No problem.
> Tier 3 targets should attempt to implement as much of the standard libraries
as possible and appropriate (core for most targets, alloc for targets that can
support dynamic memory allocation, std for targets with an operating system or
equivalent layer of system-provided functionality), but may leave some code
unimplemented (either unavailable or stubbed out as appropriate), whether
because the target makes it impossible to implement or challenging to implement.
The authors of pull requests are not obligated to avoid calling any portions of
the standard library on the basis of a tier 3 target not implementing those
portions.
With this first PR, only core is supported. I am working on support for the std
library and intend to submit that once all the tests are passing.
> The target must provide documentation for the Rust community explaining how to
build for the target, using cross-compilation if possible. If the target
supports running binaries, or running tests (even if they do not pass), the
documentation must explain how to run such binaries or tests for the target,
using emulation if possible or dedicated hardware if necessary.
This is documented in `src/doc/rustc/src/platform-support/lynxos178.md`.
> Tier 3 targets must not impose burden on the authors of pull requests, or
other developers in the community, to maintain the target. In particular, do not
post comments (automated or manual) on a PR that derail or suggest a block on
the PR based on a tier 3 target. Do not send automated messages or notifications
(via any medium, including via `@)` to a PR author or others involved with a PR
regarding a tier 3 target, unless they have opted into such messages.
> Backlinks such as those generated by the issue/PR tracker when linking to an
issue or PR are not considered a violation of this policy, within reason.
However, such messages (even on a separate repository) must not generate
notifications to anyone involved with a PR who has not requested such
notifications.
Understood.
> Patches adding or updating tier 3 targets must not break any existing tier 2
or tier 1 target, and must not knowingly break another tier 3 target without
approval of either the compiler team or the maintainers of the other tier 3
target.
> In particular, this may come up when working on closely related targets, such
as variations of the same architecture with different features. Avoid
introducing unconditional uses of features that another variation of the target
may not have; use conditional compilation or runtime detection, as appropriate,
to let each target run code supported by that target.
As far as I know this change does not affect any other targets.
> Tier 3 targets must be able to produce assembly using at least one of rustc's
supported backends from any host target. (Having support in a fork of the
backend is not sufficient, it must be upstream.)
Many targets produce assembly for x86_64 so that also works for LynxOS-178.
Add test for issue 125668
closes: #125668
The issue stemmed from improper handling of const {} blocks used in array length expressions. As of rustc 1.80.0-nightly (804421dff 2024-06-07), this ICE no longer occurs and the code compiles successfully 😀
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
Stabilize `-Zdwarf-version` as `-Cdwarf-version`
I propose stabilizing `-Zdwarf-version` as `-Cdwarf-version`. This PR adds a new `-Cdwarf-version` flag, leaving the unstable `-Z` flag as is to ease the transition period. The `-Z` flag will be removed in the future.
# `-Zdwarf-version` stabilization report
## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
No RFC/MCP, this flag was added in https://github.com/rust-lang/rust/pull/98350 and was not deemed large enough to require additional process.
The tracking issue for this feature is #103057.
## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
None that has been extensively debated but there are a few questions that could have been chosen differently:
1. What should the flag name be?
The current flag name is very specific to DWARF. Other debuginfo formats exist (msvc's CodeView format or https://en.wikipedia.org/wiki/Stabs) so we could have chosen to generalize the flag name (`-{C,Z} debuginfo-version=dwarf-5` for example). While this would extend cleanly to support formats other than DWARF, there are some downsides to this design. Neither CodeView nor Stabs have specification or format versions so it's not clear what values would be supported beyond `dwarf-{2,3,4,5}` or `codeview`. We would also need to take care to ensure the name does not lead users to think they can pick a format other than one supported by the target. For instance, what would `--target x86_64-pc-windows-msvc -Cdebuginfo-version=dwarf-5` do?
2. What is the behavior when flag is used on targets that do not support DWARF?
Currently, passing `-{C,Z} dwarf-version` on targets like `*-windows-msvc` does not do anything. It may be preferable to emit a warning alerting the user that the flag has no effect on the target platform. Alternatively, we could emit an error but this could be annoying since it would require the use of target specific RUSTFLAGS to use the flag correctly (and there isn't a way to target "any platform that uses DWARF" using cfgs).
3. Does the precompiled standard library potentially using a different version of DWARF a problem?
I don't believe this is an issue as debuggers (and other such tools) already must deal with the possibility that an application uses different DWARF versions across its statically or dynamically linked libraries.
## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those.
No extensions per se, although future DWARF versions could be considered as such. At present, we validate the requested DWARF version is between 2 and 5 (inclusive) so new DWARF versions will not automatically be supported until the validation logic is adjusted.
## Summarize the major parts of the implementation and provide links into the code (or to PRs)
- Targets define their preferred or default DWARF version: 34a5ea911c/compiler/rustc_target/src/spec/mod.rs (L2369)
- We use the target default but this can be overriden by `-{C,Z} dwarf-version` 34a5ea911c/compiler/rustc_session/src/session.rs (L738)
- The flag is validated 34a5ea911c/compiler/rustc_session/src/session.rs (L1253-L1258)
- When debuginfo is generated, we tell LLVM to use the requested value or the target default 34a5ea911c/compiler/rustc_codegen_llvm/src/debuginfo/mod.rs (L106)
## Summarize existing test coverage of this feature
- Test that we actually generate the appropriate DWARF version
- https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf5.rs
- https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf4.rs
- Test that LTO with different DWARF versions picks the highest version
- https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf-mixed-versions-lto.rs
- Test DWARF versions 2-5 are valid while 0, 1 and 6 report an error
- https://github.com/rust-lang/rust/blob/master/tests/ui/debuginfo/dwarf-versions.rs
- Ensure LLVM does not report a warning when LTO'ing different DWARF versions together
- https://github.com/rust-lang/rust/blob/master/tests/ui/lto/dwarf-mixed-versions-lto.rs
## Has a call-for-testing period been conducted? If so, what feedback was received?
No call-for-testing has been conducted but Rust for Linux has been using this flag without issue.
## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
All reported bugs have been resolved.
## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- Initial implementation in https://github.com/rust-lang/rust/pull/98350 by `@pcwalton`
- Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in https://github.com/rust-lang/rust/pull/117962 by `@weihanglo.`
- Refactoring & cleanups (#135739), fix LLVM warning on LTO with different DWARF versions (#136659) and argument validation (#136746) by `@wesleywiser`
## What FIXMEs are still in the code for that feature and why is it ok to leave them there?
No FIXMEs related to this feature.
## What static checks are done that are needed to prevent undefined behavior?
This feature cannot cause undefined behavior.
We ensure the DWARF version is one of the supported values [here](34a5ea911c/compiler/rustc_session/src/session.rs (L1255-L1257)).
## In what way does this feature interact with the reference/specification, and are those edits prepared?
No changes to reference/spec, unstable rustc docs are moved to the stable book as part of the stabilization PR.
## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
No.
## What other unstable features may be exposed by this feature?
`-Zembed-source` requires use of DWARF 5 extensions but has its own feature gate.
## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.?
No support needed for rustdoc, clippy, rust-analyzer, rustfmt or rustup.
Cargo could expose this as an option in build profiles but I would expect the decision as to what version should be used would be made for the entire crate graph at build time rather than by individual package authors.
cc-rs has support for detecting the presence of `-{C,Z} dwarf-version` in `RUSTFLAGS` and providing the corresponding flag to Clang/gcc (https://github.com/rust-lang/cc-rs/pull/1395).
---
Closes#103057
Split `TypeFolder` and `FallibleTypeFolder` atwain
Right now there is a coherence problem with `TypeFolder` and `FallibleTypeFolder`. Namely, it's impossible to implement a `FallibleTypeFolder` that is generic over interner, b/c it has a *downstream* conflict with the blanket impl:
```
impl<I, F> FallibleTypeFolder<I> for F where F: TypeFolder<I> {}
```
Because downstream crates may implement `TypeFolder<SomeLocalInterner>` for the fallible type folder.
This PR removes the relationship between `FallibleTypeFolder` and `TypeFolder`; it leads to *modest* code duplication, but otherwise does not affect perf and really doesn't matter in general.
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.
Chris Denton
bors
Matthias Krüger
Jieyou Xu
Nicholas Nethercote