cleanup: move c-variadic arguments handling into compute_inputs_and_output
Previously, ``unnormalized_input_tys`` needs to be mutable because the c_variadic arguments are added to ``unnormalized_input_tys`` outside of ``compute_inputs_and_output``. This could have been done together in ``compute_inputs_and_output``.
Enable thumb interworking on ARMv7A/R and ARMv8R bare-metal targets
This flag enables the `#[instruction_set(arm::t32)]` for the armv7a/armv7r/armv8r targets, which all support Thumb interwork but were missing this flag.
Target maintainers are `@chrisnc,` `@rust-lang/arm-maintainers,` `@rust-embedded/arm` (including me).
`crate::io::Result` → `io::Result` in most places
I don't know why many places refer to the type as `crate::io::Result` when `crate::io` is already imported.
Remove `feature(string_deref_patterns)`
The older `string_deref_patterns` feature has been superseded by the newer and more general `deref_patterns` feature. Removing string-deref-patterns allows us to get rid of a few tricky special cases in match lowering, which are different from the special cases used by deref-patterns.
The handful of existing tests for `string_deref_patterns` have been migrated to use `deref_patterns` instead. Current nightly users of the older feature should hopefully be able to migrate to the newer feature without too much trouble.
Note that `deref_patterns` is currently marked as an “incomplete” feature, because it doesn't have an accepted RFC. But `string_deref_patterns` doesn't appear to have ever had an accepted RFC either, so arguably it should have been marked incomplete too.
---
- Tracking issue for both features: https://github.com/rust-lang/rust/issues/87121
- Original implementation: https://github.com/rust-lang/rust/pull/98914
- [Zulip thread: Can we remove `#![feature(string_deref_patterns)]`?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Can.20we.20remove.20.60.23!.5Bfeature.28string_deref_patterns.29.5D.60.3F/with/565787352)
RISC-V: Implement (Zkne or Zknd) intrinsics correctly
On rust-lang/stdarch#1765, it has been pointed out that two RISC-V (64-bit only) intrinsics to perform AES key scheduling have wrong target feature.
`aes64ks1i` and `aes64ks2` instructions require *either* Zkne (scalar cryptography: AES encryption) or Zknd (scalar cryptography: AES decryption) extension (or both) but corresponding Rust intrinsics (in `core::arch::riscv64`) required *both* Zkne and Zknd extensions.
An excerpt from the original intrinsics:
```rust
#[target_feature(enable = "zkne", enable = "zknd")]
```
To fix that, we need to:
1. Represent a condition where *either* Zkne or Zknd is available and
2. Workaround an issue: `llvm.riscv.aes64ks1i` / `llvm.riscv.aes64ks2` LLVM intrinsics require either Zkne or Zknd extension.
This PR attempts to resolve them by:
1. Adding a perma-unstable RISC-V target feature: `zkne_or_zknd` (implied from both `zkne` and `zknd`) and
2. Using inline assembly to construct machine code directly (because `zkne_or_zknd` alone cannot imply neither Zkne nor Zknd, we cannot use LLVM intrinsics).
The author confirmed that we can construct an AES key scheduling function with decent performance using fixed `aes64ks1i` and `aes64ks2` intrinsics (with optimization enabled).
Corretly link URL in internal Windows docs
```
warning: this URL is not a hyperlink
--> library/std/src/sys/pal/windows/mod.rs:337:5
|
337 | /// https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: bare URLs are not automatically turned into clickable links
= note: `#[warn(rustdoc::bare_urls)]` on by default
help: use an automatic link instead
|
337 | /// <https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail>
| + +
```
Allow inline calls to offload intrinsic
Removes explicit insertion point handling and recovers the pointer at the end of the saved basic block.
r? `@ZuseZ4`
fixes: https://github.com/rust-lang/rust/issues/150413
Port `#[instruction_set]` to attribute parser
Please note the test changes, and deprecation of `E0778` and `E0779`
In my opinion, all errors related to this attribute are improved I think, except for if you have `#[instruction_set(arm::)]` in which case there's an `error: expected identifier, found <eof>`, which is quite unhelpful I think, but this seems to be a limitation of the general attribute parsing flow
r? `@JonathanBrouwer`
Fix Typos in Platform Support Tables
3 recently demoted targets had their entries moved to the tier 3 table without adjusting for the extra "host" column, this PR adds an empty column so they display correctly.
2 recently promoted targets had the opposite problem, also fixed.
While doing that I noticed that empty columns were represented inconsistently throughout the file so I normalized them all to be 2 spaces, which seemed to be the majority opinion (139 instances vs 5 for 1 space and 19 for 3 spaces).
Closes: rust-lang/rust#150499
Enable file locking support for Hurd
like Illumos (rust-lang/rust#148322) and aix (rust-lang/rust#148619), Hurd was missed when originally
introducing locking gates per target OS in rust-lang/rust#132977. building rustc on Hurd was
broken as a result since 1.91.
Adds a regression test for #137823
Adds a regression test for rust-lang/rust#137823. The test ensures that recursive generic function instantiation properly triggers the recursion limit error instead of ICE-ing with `type variables should not be hashed`.
Closesrust-lang/rust#137823
mir_build: Add a `SliceLenOp` enum for use by slice-length cases/tests
The main change in this PR introduces a `SliceLenOp` enum, to be used by the enum variants for slice-length tests in match lowering.
Slice-length tests must distinguish between `==` tests, and `>=` tests. The existing code represents this distinction with either a boolean (in `TestableCase`) or a `mir::BinOp` (in `TestKind`). Using a dedicated enum makes it easier to see what the two possible values represent.
This PR also includes a few relevant cleanups that would otherwise conflict.
r? Nadrieril
Cleanup linked list
- Replaces some checked_sub().unwrap_or(0) with saturating_sub().
- Replaces NonNull::from(Box::leak(node)) with Box::into_non_null(node)
Simplify `TypeFreshener` methods.
`freshen_{ty,const}` take a `Result` and just do a fold if the input is `Ok`. It's simpler to do those folds at the call site, and only call `freshen_{ty,const}` in the `Err` case. That way we can also avoid useless fold operations on the results of `new_{int,uint,float}`.
Also, make some `bug!` calls more concise.
r? `@lcnr`
[rustdoc] If line number setting is disabled, do not make line numbers take space
While working on https://github.com/rust-lang/rust/pull/150395, I realized that when enabled then disabled the "show line numbers" setting, instead of looking like initially:
<img width="904" height="148" alt="Screenshot From 2025-12-26 16-51-44" src="https://github.com/user-attachments/assets/a24df2f2-61be-4db5-b60f-519b35425fd2" />
The "space" taken by line numbers was still there:
<img width="904" height="148" alt="Screenshot From 2025-12-26 16-51-41" src="https://github.com/user-attachments/assets/b44af75d-52a4-4401-98e4-602b16bf6b9b" />
This PR fixes it.
First commit cleans up the `utils.goml` file a bit, I think I'll do more cleanup because switching the settings without reloading the page should make GUI tests a bit faster.
r? `@yotamofek`
Accommodate LLVM PassPlugin rename
LLVM [recently moved](https://github.com/llvm/llvm-project/pull/173279) their `PassPlugin` files to a new folder. This PR updates our `PassWrapper` to point to the new location.
refactor `destructure_const`
r? BoxyUwU
as you suggested yesterday (will add more context like links when it stops being a draft)
tried to split this into some meaningful commits hope it help ^^
Add more `unbounded_sh[lr]` examples
Inspired by rust-lang/rust#149837, which added more stuff to `wrapping_sh[lr]`, including a cross-reference to these methods.
Fix ICE by rejecting const blocks in patterns during AST lowering (closes#148138)
This PR fixes the ICE reported in rust-lang/rust#148138.
The root cause is that `const` blocks aren’t allowed in pattern position, but the AST lowering logic still attempted to create `PatExprKind::ConstBlock`, allowing invalid HIR to reach type checking and trigger a `span_bug!`.
Following the discussion in the issue, this patch removes the `ConstBlock` lowering path from `lower_expr_within_pat`. Any `ExprKind::ConstBlock` inside a pattern is now handled consistently with other invalid pattern expressions.
A new UI test is included to ensure the compiler reports a proper error and to prevent regressions.
Closesrust-lang/rust#148138.
std: sys: fs: uefi: Implement readdir
- Tested on OVMF.
- Add path field to uefi file since this will also be required in
implementing Debug for rust File.
``@rustbot`` label +O-UEFI
parser/lexer: bump to Unicode 17, use faster unicode-ident
Hello,
Bump the unicode version used by lexer/parser to 17.0.0 by updating:
- `unicode-normalization` to 0.1.25
- `unicode-properties` to 0.1.4
- `unicode-width` to 0.2.2
and by replacing `unicode-xid` with `unicode-ident` which is also 6 times faster.
I think it might be worth to run the benchmarks to double check.
(`unicode-ident` is already in `src/tools/tidy/src/deps.rs`)
Thanks!
Implement round-ties-to-even for Duration Debug for consistency with f64
## Summary
This PR proposes a fix for rust-lang/rust#103747 implementing IEEE-754 S4.3 roundTiesToEven for Duration Debug implementation.
## Testing
Added new test in `time.rs` for validating roundTiesToEven behavior in Duration formatting. Reran all debug formatting tests in `time.rs` with `./x test library/coretests --test-args time::debug_formatting`.
Improve missing core error for tier 3 targets
Tier 3 targets can't be installed via rustup, so don't recommend that. Additionally, do recommend build-std on stable because it's the recommended way to use these targets, people should switch to nightly.
Document default SOCK_CLOEXEC flag on new UnixStream
Currently, the `std::os::unix::net::UnixStream` docs do not specify that the SOCK_CLOEXEC flag is set on new sockets. This commit adds a note clarifying that, in line with the note abuot the `MSG_NOSIGNAL` flag.
rustdoc: fix duplicate Re-exports sections
Fixesrust-lang/rust#150211
When a module contains both `pub extern crate` and `pub use` items, they were being rendered under two separate "Re-exports" section headers instead of one.
This fix tracks the current section and only renders a new header when the section actually changes, consolidating items that belong to the same section under a single header.
Don't use `matches!` when `==` suffices
In the codebase we sometimes use `matches!` for values that can actually just be compared. Replace them with `==`.
Subset of rust-lang/rust#149933.
Document relative and absolute paths handling in `--remap-path-prefix`
After what we have been through with https://github.com/rust-lang/rust/pull/150110 and https://github.com/rust-lang/rust/pull/150283 in the compiler, I think it would be good to document the user-facing parts of the relative and absolute paths handling in `--remap-path-prefix`.
r? `@jieyouxu`
Port `#[rustc_must_implement_one_of]` to attribute parser
Stumbled upon a weird (bug ?) behaviour while making this PR
it seems like it is possible to reach `check_attr.rs` checks without the attribute allowed target checks having already been finished, I added a comment about how to reproduce this in `check_attr.rs`
otherwise good to note is that a bunch of code was moved from `compiler/rustc_hir_analysis/src/collect.rs` to `check_attr.rs`
r? `@JonathanBrouwer`
compiler/middle/lint: Suggest `#[expect(dead_code)]` instead of `#[allow(dead_code)]`
Until now the compiler suggested
> help: to override `-W unused` add `#[allow(dead_code)]`
when encountering e.g. an unused function in the codebase.
This PR changes the suggestion to `#[expect(dead_code)]`, which will warn again once the code is being used somewhere. This is helpful because it lets the developer know that the attribute can now be removed again. Without this the codebase will eventually be littered with stray `#[allow(dead_code)]` attributes that are no longer serving any purpose.
This was suggested in https://bsky.app/profile/steveklabnik.com/post/3m2uh7pf6e225 and I agreed strongly enough to take a look and implement it 😆
Write file with channel to S3
This will let rustup-toolchain-install-master gain support for installing stable artifacts, which is currently only possible when explicitly overriding the channel. That in turn will unblock letting Crater kick off a beta run as soon as both a new beta and a new stable artifact are ready, rather than waiting until the actual release.
rustdoc: fix incorrect type filter name in help popup
Fixesrust-lang/rust#150349
The help popup states that `const:` is an accepted search filter, but the actual filter name is `constant:`. This updates the help text to match the implementation.
Fix some divergences with the cg_clif subtree
For some reason git-subtree incorrectly synced those changes.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Fix compile issue in Vita libstd
Unfortunately it looks like the Vita libc does not support
the "utimensat" function, which is needed for setting file times.
To fix the build, this commit marks Vita as unsupported for the
function that sets the file times.
Include rustc version in ICE messages
Rather than only including them in the ICE file. Not every user includes the ICE file in their bug reports, nor do they always list the rustc version.
Disable f16 on LoongArch for LLVM < 21
The `f16` type works on the LoongArch target starting from LLVM 21. However, the current minimum supported external LLVM version is 20, so `f16` must not be enabled on LoongArch for LLVM version < 21.
Avoid using env::temp when linking a binary
This keeps all build artefacts (even temporary ones) within the build directory.
Fixesrust-lang/rust#139963
`target_features::Stability`: tweak docs of `requires_nightly()`
* No method named `allow_toggle()` exists on the type, but based on the documentation of both `requires_nightly()` and `toggle_allowed()` it seems that `toggle_allowed()` is the intended method to mention.
* Add `()` to the mention of `in_cfg()` to make it clear that a method is being referred to, and to match the presence of `()` in the mention of `toggle_allowed()`.
std: remove unsupported pipe module from VEXos pal
rust-lang/rust#146794 moved `pipe` implementations out of PAL and into a toplevel `sys` module. While most targets supporting libstd were updated, the PR did not remove the old module from the `vexos` PAL, causing builds to fail on the `armv7a-vex-v5` target.
<img width="2258" height="322" alt="image" src="https://github.com/user-attachments/assets/3bdb83f9-e577-4795-9d20-0ae4ab5d505c" />
This PR removes the old module path in the PAL and allows `vexos` targets to fall back to the `unsupported` implementation in sys/pipe.
compiletest: Add `LineNumber` newtype to avoid `+1` magic here and there
Start small. If it works well we can increase usage bit by bit as time passes.
My main motivation for doing this is to get rid of the `+ 1` I otherwise have to add in https://github.com/rust-lang/rust/pull/150201 on this line:
```rs
crate::directives::line::line_directive(file, zero_based_line_no + 1, &line)
```
But I think this is a nice general improvement by itself.
Note that we keep using "0" to represent "no specific line" because changing to `Option<LineNumber>` everywhere is a very noisy and significant change. That _can_ be changed later if wanted, but let's not do it now.
Support syntax for one-line trait reuse
This PR adds support for reusing the whole trait with a one-line reuse syntax and is part of the delegation feature rust-lang/rust#118212:
```rust
trait T {
fn foo(&self);
}
struct S;
impl T for S { ... }
struct Wrapper(S);
reuse impl T for Wrapper { self.0 }
```
The core idea is that we already have support for glob reuse, so in this scenario we want to transform one-line reuse into a trait impl block with a glob reuse in the following way:
```rust
//Before
reuse impl T for Wrapper { self.0 }
//After
impl T for Wrapper {
reuse T::* { self.0 }
}
```
It seems like this task can be solved during parsing stage, when we encountered a one-line trait reuse, we can expand into this impl block right away, and the code which was already written to expand glob delegations will take care about the rest. We will copy trait path into glob reuse path.
The implementation of the transformation reuses already existing methods for `impl` parsing, however, we do not parse inner `impl` items, instead we parse "inner items" as delegation body. Thus, we do not have to deal with generics, consts, unsafe and other `impl` related features.
Other syntax possibility is trying to shorten one-line reuse by replacing `impl` keyword with `reuse` keyword:
```rust
reuse T for Wrapper { self.0 }
```
In this case implementation may become more complicated, and the syntax more confusing, as keywords such as `const` or `unsafe` will precede `reuse`, and there are also generics:
```rust
unsafe reuse<T1, T2> T for Wrapper { self.0 }
```
In the first (currently implemented) version reuse is placed in the beginning of the item, and it is clear that we will reuse trait implementation, while in the second, shorter version, the `reuse` keyword may be lost in generics and keywords that may precede `impl`.
r? ``@petrochenkov``
Don't lint on interior mutable `const` item coming from derefs
This PR fixes the `const_item_interior_mutations` lint so we don't lint on interior mutable `const` item coming from derefs.
Fixes https://github.com/rust-lang/rust/issues/150157
Detail expectation on non-`()` block tail in `if` then condition with no `else`
When encountering an `if` expression with no `else` where the then block has a tail expression, we emit an E0308 type error. We now explain why `()` was expected.
Partially address rust-lang/rust#144911.
fix ICE when {{root}} appears in import suggestions
Fixesrust-lang/rust#150103
When wrong nested imports like `use A::{::Fish}` were used, the internal {{root}} would appear in diagnostic suggestions, causing an ICE in `join_path_idents` which asserted that **{{root}} should only appear at the start of a path**.
r? ``@matthiaskrgr``
Port `#[cfi_encoding]` to attribute parser
The error message is kind of saying the same thing twice, would like input on which .expect function I should use instead to not have it be double, otherwise this passes all tests locally where this attribute is used
r? `@JonathanBrouwer`
crash test readme: point to rustc-dev-guide
There is information that is duplicated here and in rustc-dev-guide, and the latter is more comprehensive, so point there.
Fix d32 usage in Arm target specs
Fixes https://github.com/rust-lang/rust/issues/149399 - after checking with an LLVM engineer Rust's feature implications do correctly map to LLVM's. The target specs originally had +vfp3,+d16, but were mistakenly fixed to +vfp3,-d32 which disables vfp3 again.
Some targets specify +vfp2,-d32, and since vfp2 shouldn't imply d32 the -d32 is unneeded.
The list of Arm features is quite old and since Arm is now a target maintainer of many of them we'll go in and update them. We should probably add vfp3d16 and similar as rust has no way to express these right now after d16 was removed.
The LLVM features expand like this:
```
vfp4 -> vfp3 + fp16 + vfp4d16 + vfp4sp
vfp4d16 -> vfp3d16 + fp16 + fp64 + vfp4d16sp
vfp4sp -> vfp3sp + fp16 + d32 + vfp4d16sp
vfp4d16sp -> vfp3d16sp + fp16
vfp3 -> vfp2 + vfp3d16 + vfp3sp
vfp3d16 -> vfp2 + fp64 + vfp3d16sp
vfp3sp -> vfp2 + d32 + vfp3d16sp
vfp3d16sp -> vfp2sp
vfp2 -> vfp2sp + fp64
vfp2sp -> fpregs
```
`-neon` might be unnecessary too in many of these cases, but some default CPUs that Rust specifies will turn Neon on so that needs a bit more care. I can't see any LLVM cpus that enable D32.
Old description:
> Fixes https://github.com/rust-lang/rust/issues/149399 - this implication was likely a mistake and isn't enforced by LLVM. This is is a breaking change and any users specifying `vfp2/3/4` via `-Ctarget-features` or the `target_feature` attribute will need to add `d32` in to get the same behaviour. The target features are unstable so this is ok for Rust, and this is necessary as otherwise there's no way to specify a `vfp2-d16` configuration, for example.
>
> I expect these targets would have been broken by https://github.com/rust-lang/rust/pull/149173 as `-d32` would have disabled any `+vfpX` feature before it. With the removal of the implication the `-d32` went back to being unnecessary, but I've removed it anyway.
>
> As ``@RalfJung`` pointed out, thumbv7a-nuttx-eabihf looks to have been relying on this implication so I've added `+d32` to it's target spec.
Port `#[thread_local]` to attribute parser
Simple port, only thing that might be an issue is the `help: #[thread_local] can be applied to foreign statics and statics` it probably would be that if an attribute is applicable to both statics and foreign statics that we don't alphabetically sort them next to each other, because now it kinda reads like `#[thread_local]` is something that you primarily use on foreign statics
r? `@JonathanBrouwer`
Dogfood `strip_circumfix`
cc rust-lang/rust#147946
Truth be told, I expected to find more places where this can be used in the compiler.
Seems cargo, clippy and rustfmt can use this much more frequently, but I'll have to wait (I think?) for the next two-way sync to be able to dogfood it in those repos.
Subtree sync for rustc_codegen_cranelift
Nothing too exciting since the last sync.
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Fixed ICE for EII with multiple defaults due to duplicate definition in nameres
r? ``@jieyouxu`` (since you looked at the other one)
Fixes https://github.com/rust-lang/rust/issues/149982
Previously a [fix was proposed](https://github.com/rust-lang/rust/pull/149985) by ``@SATVIKsynopsis`` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR.
Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined.
Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption.
The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error.
Thanks to ``@SATVIKsynopsis`` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3
Also thanks to ``@yaahc`` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3
The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)
tests/run-make-cargo/same-crate-name-and-macro-name: New regression test
Closes https://github.com/rust-lang/rust/issues/71259 which just **E-needs-test**. See https://github.com/rust-lang/rust/issues/71259#issuecomment-615879925 for a good description of what we should test (which we do in this PR).
The project we add fails with an old nightly without the fix:
```console
$ cargo +nightly-2020-03-10 run
Compiling consumer v0.1.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer)
Finished dev [unoptimized + debuginfo] target(s) in 0.14s
Running `target/debug/consumer`
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `"version 1"`,
right: `"version 2"`', src/main.rs:6:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
and passes with a recent toolchain:
```console
$ cargo run
warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024
warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v1/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024
warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v2/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024
Compiling mylib v2.0.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v2)
Compiling mylib v1.0.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v1)
Compiling consumer v0.1.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.14s
Running `target/debug/consumer`
```
in other words, the test tests what it should and will catch regressions.
std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features
This synchronizes the list with the current state of `sysctl` on macOS “Tahoe” 26.2.
r? ``@Amanieu``
Support recursive delegation
This PR adds support for recursive delegations and is a part of the delegation feature rust-lang/rust#118212.
r? ``@petrochenkov``
Generate macro expansion for rust compiler crates docs
This enables the `--generate-macro-expansion` rustdoc flag, generating possibility to expand macros directly in source code pages (https://github.com/rust-lang/rust/pull/137229).
Needed this new feature when I was working on https://github.com/rust-lang/rust/pull/149919 and I thought "why not enable it by default?". So here we go.
Not too sure who to r? here so:
r? ``@kobzol``
Suggest struct pattern when destructuring Range with .. syntax
implemented a new diagnostic in rustc_resolve to detect invalid range destructuring attempts (e.g., let start..end = range). The fix identifies when resolution fails for identifiers acting as range bounds specifically handling cases where bounds are parsed as expressions and suggests the correct struct pattern syntax (std::ops::Range { start, end }). This replaces confusing "cannot find value" errors with actionable help, verified by a new UI test covering various identifier names.
Fixesrust-lang/rust#149777
Set -Cpanic=abort in windows-msvc stack protector tests
I ran into a test failure with the 32-bit windows test on https://github.com/rust-lang/rust/pull/117192, one of the tests has been incorrectly passing (until my change!) because it is picking up the stack protector from another function. I've tried to prevent that happening again by adding CHECK-DAGs for the start and end of each function.
I've also done my best to correct the comments, some were based on the fact that we used to run these tests with unwinding panics, but LLVM doesn't add protectors to function with SEH funclets so it's must more straightforward for these tests to use `-Cpanic=abort`.
Expand `str_as_str` to more types
Tracking issue: rust-lang/rust#130366
ACP: https://github.com/rust-lang/libs-team/issues/643
This PR expands `str_from_str` feature and adds analogous methods to more types. Namely:
- `&CStr`
- `&[T]`, `&mut [T]`
- `&OsStr`
- `&Path`
- `&ByteStr`, `&mut ByteStr` (tracking issue: rust-lang/rust#134915) (technically was not part of ACP)
[rustdoc] Fix invalid handling of field followed by negated macro call
This is the bug uncovered in https://github.com/rust-lang/rust/pull/150022. Once fixed Ill rebuild all compiler docs and see if we can enable the option for compiler docs. =D
It's a weird case where we extracted some tokens out of the iterator and then, when checking next items (from this iterator), it didn't find the `:` token, and therefore badly assumed the token kind.
The solution I came up with is to instead not extract tokens from the iterator and to count how many tokens are in the current path. So when iterate over the items, instead of having a mix of extracted tokens and tokens still inside the iterator, we now only iterate over the iterator.
The biggest change here is that `get_full_ident_path` will return an option instead of a `Vec`, and if it's contains `:` (one, not two), then it will return `None` and the `:` will be handled like any token and not like a path (which is more correct imo).
r? `@yotamofek`
Port `#[rustc_no_implicit_autorefs]`, `#[rustc_lint_opt_ty]`, and `#[rustc_lint_query_instability]` attributes to be parsed
This PR ports three simple internal rustc attributes to be parsed in a single PR to avoid having to resolve multiple rebase confilicts
r? ``@JonathanBrouwer``
Tidying up tests/ui/issues 14 tests [5/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
move `tests/ui/inherent-impls-overlap-check` to `tests/ui/duplicate/inherent-impls-overlap-check`.
r? Kivooeo
Port `#[rustc_never_returns_null_ptr]` to attribute parser
Ports `#[rustc_never_returns_null_ptr]` to be parsed using the attribute parser
r? `@JonathanBrouwer`
Avoid unhelpful suggestion when crate name is invalid
Pointing out they can set the crate's name is non-actionable: their problem is they found out how and set it incorrectly. Remove extraneous information that can only confuse the matter.
Implement va_arg for Hexagon targets
Implements proper variadic argument handling for hexagon-unknown-linux-musl targets using a 3-pointer VaList structure compatible with LLVM's HexagonBuiltinVaList implementation.
* Handles register save area vs overflow area transition
* Provides proper 4-byte and 8-byte alignment for arguments
* Only activates for hexagon+musl targets via Arch::Hexagon & Env::Musl
Jonathan Brouwer