| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
Fixes rust-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);
```
|
|
tests: Convert two handwritten minicores to add-core-stubs
|
|
Require generic params for const generic params
I think that was just an oversight when the support for them was added
r? `@BoxyUwU` or `@camelid`
fixes rust-lang/rust#137188
fixes rust-lang/rust#138166
fixes rust-lang/rust#138240
fixes rust-lang/rust#138266
fixes rust-lang/rust#138359
|
|
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`
|
|
workingjubilee:rework-gpu-kernel-feature-gate-test, r=jieyouxu
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.
|
|
add Vec::peek_mut
Tracking issue: rust-lang/rust#122742
|
|
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](https://github.com/rust-lang/rust/pull/109278/commits/af945cb86e03b44a4b6dc4d54ec1424b00a2349e).
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#128425 (Make `missing_fragment_specifier` an unconditional error)
- rust-lang/rust#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features)
- rust-lang/rust#140770 (add `extern "custom"` functions)
- rust-lang/rust#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches)
- rust-lang/rust#142248 (Add supported asm types for LoongArch32)
- rust-lang/rust#142267 (assert more in release in `rustc_ast_lowering`)
- rust-lang/rust#142274 (Update the stdarch submodule)
- rust-lang/rust#142276 (Update dependencies in `library/Cargo.lock`)
- rust-lang/rust#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library)
Failed merges:
- rust-lang/rust#140920 (Extract some shared code from codegen backend target feature handling)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#134847 (Implement asymmetrical precedence for closures and jumps)
- rust-lang/rust#141491 (Delegate `<CStr as Debug>` to `ByteStr`)
- rust-lang/rust#141770 (Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code)
- rust-lang/rust#142069 (Introduce `-Zmacro-stats`)
- rust-lang/rust#142158 (Tracking the old name of renamed unstable library features)
- rust-lang/rust#142221 ([AIX] strip underlying xcoff object)
- rust-lang/rust#142340 (miri: we can use apfloat's mul_add now)
- rust-lang/rust#142379 (Add bootstrap option to compile a tool with features)
- rust-lang/rust#142410 (intrinsics: rename min_align_of to align_of)
- rust-lang/rust#142413 (rustc-dev-guide subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
r=petrochenkov,traviscross
Make `missing_fragment_specifier` an unconditional error
This was attempted in [1] then reverted in [2] because of fallout. Recently, this was made an edition-dependent error in [3].
Make missing fragment specifiers an unconditional error again, across all editions.
More context: https://github.com/rust-lang/rust/pull/128006
Most recent crater: https://github.com/rust-lang/rust/pull/128425#issuecomment-2686949847
Fixes: https://github.com/rust-lang/rust/issues/40107
[1]: https://github.com/rust-lang/rust/pull/75516
[2]: https://github.com/rust-lang/rust/pull/80210
[3]: https://github.com/rust-lang/rust/pull/128006
|
|
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;
}
```
|
|
r=ChrisDenton,RalfJung
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)]
|
```
|
|
Note when enum variants shadow an associated function
r? ``@WaffleLapkin``
Closes rust-lang/rust#142263
|
|
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.
|
|
Suggest mut when possbile for temporary value dropped while borrowed
Fixes #137486
|
|
Lint on fn pointers comparisons in external macros
This PR extends the recently stabilized `unpredictable_function_pointer_comparisons` lint ~~to also lint on `Option<{function pointer}>` and~~ as well as linting in external macros (as to catch `assert_eq!` and others).
```rust
assert_eq!(Some::<FnPtr>(func), Some(func as unsafe extern "C" fn()));
//~^ WARN function pointer comparisons
#[derive(PartialEq, Eq)]
struct A {
f: fn(),
//~^ WARN function pointer comparisons
}
```
Fixes https://github.com/rust-lang/rust/issues/134527
|
|
|
|
Add `ParseMode::Diagnostic` and fix multiline spans in diagnostic attribute lints
Best viewed commit by commit.
The first commit is a test, the commits following that are small refactors to `rustc_parse_format`. Originally I wanted to do a much larger change (doing these smaller fixes first would have that made easier to review), but ended up doing something else instead.
An observable change from this is that the diagnostic attribute no longer tries to parse align/fill/width/etc parameters. For an example (see also test changes), a string like `"{Self:!}"` no longer says "missing '}'", instead it says that format parameters are not allowed. It'll now also format the string as if the user wrote just `"{Self}"`
|
|
refactor `AttributeGate` and `rustc_attr!` to emit notes during feature checking
First commit changes the following:
- `AttributeGate ` from an enum with (four) tuple fields to (five) named fields
- adds a `notes` fields that is emitted as notes in the `PostExpansionVisitor` pass
- removes the `this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date` note if the feature gate is `rustc_attrs`.
- various phrasing changes and touchups
- and finally, the reason why I went down this path to begin with: tell people they can use the diagnostic namespace when they hit the rustc_on_unimplemented feature gate 🙈
Second commit removes unused machinery for deprecated attributes
|
|
|
|
Apply nested goals certainty to `InspectGoals` for normalizes-to
...so that normalizes-to goals don't have `Certainty::Yes` even if they have nested goals which don't hold.
r? lcnr
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
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.
Details:
- It measures code snippets by pretty-printing them and then measuring
lines and bytes. This required a bunch of additional pretty-printing
plumbing, in `rustc_ast_pretty` and `rustc_expand`.
- The measurement is done in `MacroExpander::expand_invoc`.
- The measurements are stored in `ExtCtxt::macro_stats`.
|
|
|
|
|
|
This was attempted in [1] then reverted in [2] because of fallout.
Recently, this was made an edition-dependent error in [3].
Make missing fragment specifiers an unconditional error again.
[1]: https://github.com/rust-lang/rust/pull/75516
[2]: https://github.com/rust-lang/rust/pull/80210
[3]: https://github.com/rust-lang/rust/pull/128006
|
|
|
|
|
|
|
