Fix incorrect suggestion when calling an associated type with a type anchor
`sugg_span` here is the span of the call expression.
That span here is the `<Self>::Assoc`, which is exactly what we need here (even though I would expect it to include the arguments, but I guess it doesn't)
r? ``@WaffleLapkin``
One commit with failing tests and one that fixes it for reviewability
closesrust-lang/rust#142473
variadic functions: remove list of supported ABIs from error
I think this list is problematic for multiple reasons:
- It is bound to go out-of-date as it is in a very different place from where we actually define which functions support varagrs (`fn supports_varargs`).
- Many of the ABIs we list only work on some targets; it makes no sense to mention "aapcs" as a possible ABI when building for x86_64. (This led to a lot of confusion in https://github.com/rust-lang/rust/issues/110505 where the author thought they should use "cdecl" and then were promptly told that "cdecl" is not a legal ABI on their target.)
- Typically, when the programmer wrote `extern "foobar"`, it is because they need the "foobar" ABI. It is of little use to tell them that there are other ABIs with which varargs would work.
Cc ``@workingjubilee``
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixesrust-lang/rust#79409
[rustdoc] Give more information into extracted doctest information
Follow-up of https://github.com/rust-lang/rust/pull/134531.
This update fragment the doctest code into its sub-parts to give more control to the end users on how they want to use it.
The new JSON looks like this:
```json
{
"format_version":2,
"doctests":[
{
"file":"$DIR/extract-doctests-result.rs",
"line":8,
"doctest_attributes":{
"original":"",
"should_panic":false,
"no_run":false,
"ignore":"None",
"rust":true,
"test_harness":false,
"compile_fail":false,
"standalone_crate":false,
"error_codes":[],
"edition":null,
"added_css_classes":[],
"unknown":[]
},
"original_code":"let x = 12;\nOk(())",
"doctest_code":{
"crate_level":"#![allow(unused)]\n",
"code":"let x = 12;\nOk(())",
"wrapper":{
"before":"fn main() { fn _inner() -> core::result::Result<(), impl core::fmt::Debug> {\n",
"after":"\n} _inner().unwrap() }",
"returns_result":true
}
},
"name":"$DIR/extract-doctests-result.rs - (line 8)"
}
]
}
```
for this doctest:
```rust
let x = 12;
Ok(())
```
With this, I think it matches what you need ``@ojeda?`` If so, once merged I'll update the patch I sent to RfL.
r? ``@aDotInTheVoid``
Temporary lifetime extension through tuple struct and tuple variant constructors
This makes temporary lifetime extension work for tuple struct and tuple variant constructors, such as `Some()`.
Before:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Not extended :(
let a = Some { 0: &temp() }; // Extended
```
After:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Extended
let a = Some { 0: &temp() }; // Extended
```
So, with this change, this works:
```rust
let a = Some(&String::from("hello")); // New: String lifetime now extended!
println!("{a:?}");
```
Until now, we did not extend through tuple struct/variant constructors (like `Some`), because they are function calls syntactically, and we do not want to extend the String lifetime in:
```rust
let a = some_function(&String::from("hello")); // String not extended!
```
However, it turns out to be very easy to distinguish between regular functions and constructors at the point where we do lifetime extension.
In practice, constructors nearly always use UpperCamelCase while regular functions use lower_snake_case, so it should still be easy to for a human programmer at the call site to see whether something qualifies for lifetime extension or not.
This needs a lang fcp.
---
More examples of what will work after this change:
```rust
let x = Person {
name: "Ferris",
job: Some(&Job { // `Job` now extended!
title: "Chief Rustacean",
organisation: "Acme Ltd.",
}),
};
dbg!(x);
```
```rust
let file = if use_stdout {
None
} else {
Some(&File::create("asdf")?) // `File` now extended!
};
set_logger(file);
```
```rust
use std::path::Component;
let c = Component::Normal(&OsString::from(format!("test-{num}"))); // OsString now extended!
assert_eq!(path.components.first().unwrap(), c);
```
Rework how the disallowed qualifier in function type diagnostics are generated
This pull request fixes two independent issues:
1. When qualifiers of a function type ptr are in the wrong order and one of them is async/const (not permitted on function types), the diagnostic suggests removing the incorrect qualifier. Fixes https://github.com/rust-lang/rust/issues/142268, which is an issue created by https://github.com/rust-lang/rust/pull/133151. This is fixed by moving the check into `parse_fn_front_matter`, where better span information is available to generate the right suggestions.
2. When qualifiers of a function type ptr are in the wrong order and one of them is async/const (not permitted on function types), `cargo fix` crashes because "cannot replace slice of data that was already replaced". This is fixed by not generating a suggestion for the "wrong order" diagnostic if the "disallowed qualifier" diagnostic is triggered.
There is a commit with failing tests so the test diff is clearer
r? `@jdonszelmann`
tests: Minicore `extern "gpu-kernel"` feature test
Explicitly cross-build it for GPU targets and check it errors on hosts. A relatively minor cleanup from my other ABI-related PRs that I got tired of rebasing.
builtin dyn impl no guide inference
cc https://github.com/rust-lang/rust/pull/141347
we can already slightly restrict this behavior in the old solver, so why not do so. Needs crater and an FCP.
r? `@compiler-errors`
Look at proc-macro attributes when encountering unknown attribute
```
error: cannot find attribute `sede` in this scope
--> $DIR/missing-derive-2.rs:22:7
|
LL | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Deserialize` and `Serialize` accept the similarly named `serde` attribute
|
LL | #[serde(untagged)]
| +
error: cannot find attribute `serde` in this scope
--> $DIR/missing-derive-2.rs:16:7
|
LL | #[serde(untagged)]
| ^^^^^
|
note: `serde` is imported here, but it is a crate, not an attribute
--> $DIR/missing-derive-2.rs:5:1
|
LL | extern crate serde;
| ^^^^^^^^^^^^^^^^^^^
help: `serde` is an attribute that can be used by the derive macros `Serialize` and `Deserialize`, you might be missing a `derive` attribute
|
LL + #[derive(Serialize, Deserialize)]
LL | enum B {
|
```
Partially address #47608. This PR doesn't find [macros that haven't yet been imported by name](af945cb86e).
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#138016 (Added `Clone` implementation for `ChunkBy`)
- rust-lang/rust#141162 (refactor `AttributeGate` and `rustc_attr!` to emit notes during feature checking)
- rust-lang/rust#141474 (Add `ParseMode::Diagnostic` and fix multiline spans in diagnostic attribute lints)
- rust-lang/rust#141947 (Specify that "option-like" enums must be `#[repr(Rust)]` to be ABI-compatible with their non-1ZST field.)
- rust-lang/rust#142252 (Improve clarity of `core::sync::atomic` docs about "Considerations" in regards to CAS operations)
- rust-lang/rust#142337 (miri: add flag to suppress float non-determinism)
r? `@ghost`
`@rustbot` modify labels: rollup
tests: Split dont-shuffle-bswaps along opt-levels and arches
This duplicates dont-shuffle-bswaps in order to make each opt level its own test. Then -opt3.rs gets split into a revision per arch we want to test, with certain architectures gaining new target-cpu minimums.
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features
`-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates).
* Enables target features for `-Zretpoline-external-thunk`:
`+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
* Enables target features for `-Zretpoline`:
`+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.
Also this PR forbids to specify those target features manually (warning).
Issue: rust-lang/rust#116852
intrinsics: rename min_align_of to align_of
Now that `pref_align_of` is gone (https://github.com/rust-lang/rust/pull/141803), we can give the intrinsic backing `align_of` its proper name.
r? `@workingjubilee` or `@bjorn3`
Tracking the old name of renamed unstable library features
This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification.
r? `@jdonszelmann`
There have been a lot of PR's reviewed by you lately, thanks for your time!
cc `@jyn514`
Introduce `-Zmacro-stats`
Introduce `-Zmacro-stats`.
It collects data about macro expansions and prints them in a table after expansion finishes. It's very useful for detecting macro bloat, especially for proc macros.
r? `@petrochenkov`
Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code
Follow-up of https://github.com/rust-lang/rust/pull/141747.
Thanks `@camelid` for spotting it!
r? `@camelid`
Implement asymmetrical precedence for closures and jumps
I have been through a series of asymmetrical precedence designs in Syn, and finally have one that I like and is worth backporting into rustc. It is based on just 2 bits of state: `next_operator_can_begin_expr` and `next_operator_can_continue_expr`.
Asymmetrical precedence is the thing that enables `(return 1) + 1` to require parentheses while `1 + return 1` does not, despite `+` always having stronger precedence than `return` [according to the Rust Reference](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence). This is facilitated by `next_operator_can_continue_expr`.
Relatedly, it is the thing that enables `(return) - 1` to require parentheses while `return + 1` does not, despite `+` and `-` having exactly the same precedence. This is facilitated by `next_operator_can_begin_expr`.
**Example:**
```rust
macro_rules! repro {
($e:expr) => {
$e - $e;
$e + $e;
};
}
fn main() {
repro!{return}
repro!{return 1}
}
```
`-Zunpretty=expanded` **Before:**
```console
fn main() {
(return) - (return);
(return) + (return);
(return 1) - (return 1);
(return 1) + (return 1);
}
```
**After:**
```console
fn main() {
(return) - return;
return + return;
(return 1) - return 1;
(return 1) + return 1;
}
```
compiler: Ease off the accelerator on `unsupported_calling_conventions`
This is to give us more time to discuss rust-lang/rust#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps
I believe we should consider this a simple suspension of the decision in rust-lang/rust#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
```
error: cannot find attribute `empty_helper` in this scope
--> $DIR/derive-helper-legacy-limits.rs:17:3
|
LL | #[empty_helper]
| ^^^^^^^^^^^^
|
help: `empty_helper` is an attribute that can be used by the derive macro `Empty`, you might be missing a `derive` attribute
|
LL + #[derive(Empty)]
LL | struct S2;
|
```
Look at proc-macro attributes when encountering unknown attribute
```
error: cannot find attribute `sede` in this scope
--> src/main.rs:18:7
|
18 | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Serialize` and `Deserialize` accept the similarly named `serde` attribute
|
18 | #[serde(untagged)]
| ~~~~~
error: cannot find attribute `serde` in this scope
--> src/main.rs:12:7
|
12 | #[serde(untagged)]
| ^^^^^
|
= note: `serde` is in scope, but it is a crate, not an attribute
help: `serde` is an attribute that can be used by the derive macros `Serialize` and `Deserialize`, you might be missing a `derive` attribute
|
10 | #[derive(Serialize, Deserialize)]
|
```
Detect method not being present that is present in other tuple types
When a method is not present because of a trait bound not being met, and that trait bound is on a tuple, we check if making the tuple have no borrowed types makes the method to be found and highlight it if it does. This is a common problem for Bevy in particular and ORMs in general.
<img width="1166" alt="Screenshot 2025-06-04 at 10 38 24 AM" src="https://github.com/user-attachments/assets/d257c9ea-c2d7-42e7-8473-8b93aa54b8e0" />
Address rust-lang/rust#141258. I believe that more combination of cases in the tuple types should be handled (like adding borrows and checking when a specific type needs to not be a borrow while the rest stay the same), but for now this handles the most common case.
