| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix panic and incorrectly suggested examples in `format_args` macro.
Follow up on rust-lang/rust#146123
Fixes: rust-lang/rust#146446
r? `@estebank`
|
|
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#3 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
|
|
Stabilize BTree{Map,Set}::extract_if
Tracking issue: rust-lang/rust#70530
FCP completed: https://github.com/rust-lang/rust/issues/70530#issuecomment-3191454465
Closes: rust-lang/rust#70530
|
|
Add --print target-spec-json-schema
This schema is helpful for people writing custom target spec JSON. It can provide autocomplete in the editor, and also serves as documentation when there are documentation comments on the structs, as `schemars` will put them in the schema.
I was motivated to do this because I saw someone write their own version of this schema by hand, so demand for this clearly exists. It's not a lot of effort to implement, so I thought it would make sense.
MCP: https://github.com/rust-lang/compiler-team/issues/905
I think it would also be useful to put this in the sysroot in `etc` so people can link it directly in their editors.
I would have loved to add a test that validates the JSON schema against the spec JSON of every builtin target, but I don't want to do it as the JSON schema validation crates have incredible amounts of dependencies because JSON schema supports a ton of random features. I don't want to add that, even as a dev dependency.
|
|
sort array trait implementation suggestions correctly
Fixes rust-lang/rust#135098.
Previously tried in rust-lang/rust#137428.
|
|
Convert `no_std` and `no_core` to the new attribute infrastructure
r? ```@oli-obk```
Also added a test for these, since we didn't have any and I was kind of surprised new diagnostics didn't break anything hehe
|
|
This schema is helpful for people writing custom target spec JSON. It
can provide autocomplete in the editor, and also serves as documentation
when there are documentation comments on the structs, as `schemars` will
put them in the schema.
|
|
|
|
Constify Eq, Ord, PartialOrd
Adds `#[const_trait]` and impls for `Eq`, `Ord`, `PartialOrd`. Impl for some other traits (e.g., slices and arrays) are blocked mainly on const closures (https://github.com/rust-lang/rust/issues/106003).
For TypeId Ord we need const pointer comparison (https://github.com/rust-lang/rust/issues/53020)
Tracking issue https://github.com/rust-lang/rust/issues/143800
|
|
consider item bounds for non-yet-defined opaque types
Based on rust-lang/rust#140405.
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/182
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/196
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/205
there's some jank here, see https://github.com/rust-lang/trait-system-refactor-initiative/issues/229
## Design
If the self type is an inference variable which has been sub-unified with am opaque type, we need to incompletely guide inference to avoid breakage.
In this case, we
- look at the item bounds of all sub-unified opaque types, and
- blanket impls which do not constrain the self type
Even if there are applicable candidates, we always force their certainty to be `Maybe`, so they will always have to be reproven once we've constrained the inference variable.
This is a bit iffy, see the added tests.
r? `@BoxyUwU`
|
|
|
|
test: remove an outdated normalization for rustc versions
These "you are using $RUSTC_VERSION" help messages were removed in
rust-lang/rust#142943, but rust-lang/rust#142681 started before that and
merged later, so its normalization is vestigial.
|
|
r=lolbinarycat
[rustdoc] Correctly handle literal search on paths
Fixes https://github.com/rust-lang/rust/issues/146129.
cc ```@notriddle```
r? ```@lolbinarycat```
|
|
Improve suggestion in case a bare URL is surrounded by brackets
Fixes https://github.com/rust-lang/rust/issues/146162.
With this change, output looks like this:
```
|
1 | //! [https://github.com]
| ^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<https://github.com>`
|
= note: bare URLs are not automatically turned into clickable links
= note: `#[warn(rustdoc::bare_urls)]` on by default
```
cc ```@fmease```
r? ```@lolbinarycat```
|
|
support integer literals in `${concat()}`
Tracking issue: rust-lang/rust#124225
Adds support for using integer literals as arguments to `${concat()}` macro expressions.
Integer formatting such as `1_000` is preserved by this.
|
|
match clang's `va_arg` assembly on arm targets
tracking issue: https://github.com/rust-lang/rust/issues/44930
For this example
```rust
#![feature(c_variadic)]
#[unsafe(no_mangle)]
unsafe extern "C" fn variadic(a: f64, mut args: ...) -> f64 {
let b = args.arg::<f64>();
let c = args.arg::<f64>();
a + b + c
}
```
We currently generate (via llvm):
```asm
variadic:
sub sp, sp, #12
stmib sp, {r2, r3}
vmov d0, r0, r1
add r0, sp, #4
vldr d1, [sp, #4]
add r0, r0, #15
bic r0, r0, #7
vadd.f64 d0, d0, d1
add r1, r0, #8
str r1, [sp]
vldr d1, [r0]
vadd.f64 d0, d0, d1
vmov r0, r1, d0
add sp, sp, #12
bx lr
```
LLVM is not doing a good job. In fact, it's well-known that LLVM's implementation of `va_arg` is kind of bad, and we implement it ourselves (based on clang) for many targets already. For arm, our own `emit_ptr_va_arg` saves 3 instructions.
Next, it turns out it's important for LLVM to explicitly start and end the lifetime of the `va_list`. In https://github.com/rust-lang/rust/pull/146059 I already end the lifetime, but when looking at this again, I noticed that it is important to also start it, see https://godbolt.org/z/EGqvKTTsK: failing to explicitly start the lifetime uses an extra register.
So, the combination of `emit_ptr_va_arg` with starting/ending the lifetime makes rustc emit exactly the instructions that clang generates::
```asm
variadic:
sub sp, sp, #12
stmib sp, {r2, r3}
vmov d16, r0, r1
vldr d17, [sp, #4]
vadd.f64 d16, d16, d17
vldr d17, [sp, #12]
vadd.f64 d16, d16, d17
vmov r0, r1, d16
add sp, sp, #12
bx lr
```
The arguments to `emit_ptr_va_arg` are based on [the clang implementation](https://github.com/llvm/llvm-project/blob/03dc2a41f3d9a500e47b513de5c5008c06860d65/clang/lib/CodeGen/Targets/ARM.cpp#L798-L844).
r? ``@workingjubilee`` (I can re-roll if your queue is too full, but you do seem like the right person here)
try-job: armhf-gnu
|
|
|
|
These "you are using $RUSTC_VERSION" help messages were removed in
rust-lang/rust#142943, but rust-lang/rust#142681 started before that and
merged later, so its normalization is vestigial.
|
|
|
|
|
|
|
|
Revert `assert!` desugaring changes (#122661)
Reverts rust-lang/rust#122661 to prevent rust-lang/rust#145770 slipping into beta.
cc `@estebank` (FYI)
### Review remarks
- Commit 1 is the MCVE reported in rust-lang/rust#145770 added as a regression test `tests/ui/macros/assert-desugaring-145770.rs`. Against `master`, this test fails.
- Commit 2 reverts rust-lang/rust#122661 (with a merge conflict fixed). `tests/ui/macros/assert-desugaring-145770.rs` now passes.
|
|
Less greedily parse `[const]` bounds
> [!IMPORTANT]
> If you're coming here from any beta backport nomination thread on Zulip, only the last commit is truly relevant (the first commit doesn't need to be backported, it only contains test modifications)!
Don't consider `[` to start a bound, only consider `[const]` in its entirety to do so. This drastically reduces (but doesn't eliminate!) the chance of *real* breakages. Like `const`, `~const` and `async` before, `[const]` unavoidably brings along theoretical breakages, see preexisting tests: `macro-const-trait-bound-theoretical-regression.rs` and `macro-async-trait-bound-theoretical-regression.rs`.
Side note: It's unfortunate that we have to do this but apart from the known fact that MBE hurts forward compatibility, the `[const]` syntax is simply a bit scuffed (also CC'ing https://github.com/rust-lang/rust/issues/146122, section (3)).
Fixes [after beta backport] rust-lang/rust#146417.
* 1st commit: Restore the original test intentions of several preexisting related tests that were unfortunately lost over time
* I've added a bunch of SCREAMING comments to make it less likely to be lost again
* CC PR rust-lang/rust#119099 which added most of these tests
* CC [#144409 (comment)](https://github.com/rust-lang/rust/pull/144409#discussion_r2337587513) for further context (NB: It's not the only PR that negatively affected the test intention)
* 2nd commit: Actually address the regression
r? `@oli-obk` or anyone
|
|
s390x: mark soft-float target feature as incompatible
This provides a more informative warning when someone manually sets `+soft-float` on s390x.
|
|
disable core dumps for panic-uninitialized-zeroed
That test causes a large amount of crashes. If a system has a /proc/sys/kernel/core_pattern that uploads core dumps enabled, it will take a long time to complete. Set dumpable to 0 to avoid that.
Before:
```
$ time ./panic-uninitialized-zeroed
real 0m47.457s
user 0m0.023s
sys 0m0.021s
```
After:
```
$ ./panic-uninitialized-zeroed
real 0m0.029s
user 0m0.019s
sys 0m0.010s
```
|
|
This reverts commit 1eeb8e8b151d1da7daa73837a25dc5f7a1a7fa28, reversing
changes made to 324bf2b9fd8bf9661e7045c8a93f5ff0ec1a8ca5.
Unfortunately the assert desugaring change is not backwards compatible,
see RUST-145770.
Code such as
```rust
#[derive(Debug)]
struct F {
data: bool
}
impl std::ops::Not for F {
type Output = bool;
fn not(self) -> Self::Output { !self.data }
}
fn main() {
let f = F { data: true };
assert!(f);
}
```
would be broken by the assert desugaring change. We may need to land
the change over an edition boundary, or limit the editions that the
desugaring change impacts.
|
|
Using the MCVE reported in RUST-145770.
|
|
|
|
|
|
|
|
|
|
Improve C-variadic error messages: part 2
tracking issue: https://github.com/rust-lang/rust/issues/44930
a reimplementation of https://github.com/rust-lang/rust/pull/143546 that builds on https://github.com/rust-lang/rust/pull/146165.
This PR
- disallows coroutines (e.g. `async fn`) from having a `...` argument
- disallows associated functions (both in traits and standard impl blocks) from having a `...` argument
- splits up a generic "ill-formed C-variadic function" into specific errors about using an incorrect ABI, not specifying an ABI, or missing the unsafe keyword
C-variadic coroutines probably don't make sense? C-variadic functions are for FFI purposes, combining that with async functions seems weird.
For associated functions, we're just cutting scope. It's probably fine, but it's probably better to explicitly allow it. So for now, at least give a more targeted error message.
Made to be reviewed commit-by-commit.
cc `@workingjubilee`
r? compiler
|
|
Strip frontmatter in fewer places
* Stop stripping frontmatter in `proc_macro::Literal::from_str` (RUST-146132)
* Stop stripping frontmatter in expr-ctxt (but not item-ctxt!) `include`s (RUST-145945)
* Stop stripping shebang (!) in `proc_macro::Literal::from_str`
* Not a breaking change because it did compare spans already to ensure there wasn't extra whitespace or comments (`Literal::from_str("#!\n0")` already yields `Err(_)` thankfully!)
* Stop stripping frontmatter+shebang inside some rustdoc code where it doesn't make any observable difference (see self review comments)
* (Stop stripping frontmatter+shebang inside internal test code)
Fixes https://github.com/rust-lang/rust/issues/145945.
Fixes https://github.com/rust-lang/rust/issues/146132.
r? fee1-dead
|
|
Add tests for deref on pin
Tests split out from rust-lang/rust#145608.
r? `@lcnr`
|
|
Suggest examples of format specifiers in error messages
Format macro now suggests adding `{}` if no formatting specifiers are present. It also gives an example:
```rust
LL | println!("Hello", "World");
| ------- ^^^^^^^ argument never used
| |
| formatting specifier missing
|
= note: format specifiers use curly braces: `{}`
help: consider adding format specifier
|
LL | println!("Hello{}", "World");
| ++
```
When one or more `{}` are present, it doesn't show 'format specifiers use curly braces: `{}`' and example, just small hint on how many you missing:
```rust
LL | println!("list: {}", 1, 2, 3);
| ---------- ^ ^ argument never used
| | |
| | argument never used
| multiple missing formatting specifiers
|
= help: consider adding 2 format specifiers
```
Original issue: rust-lang/rust#68293
Based on discussion in this PR: rust-lang/rust#76443
Let me know if something is missing
|
|
default auto traits: use default supertraits instead of `Self: Trait` bounds on associated items
First commit: the motivation has been discussed [here](https://github.com/rust-lang/rust/pull/144679).
Second commit: the only new places where new implicit `DefaultAutoTrait` bounds are generated are supertraits and trait object so `?Trait` syntax should be extended to these places only.
r? `@lcnr`
|
|
|
|
Trim paths less in MIR dumping
With this PR, the paths MIR dump filters and that are printed at the start of a dump file are no longer trimmed. They don't include the crate that is being compiled, however.
|
|
r=jdonszelmann,ralfjung,traviscross
Implement `#[rustc_align_static(N)]` on `static`s
Tracking issue: https://github.com/rust-lang/rust/issues/146177
```rust
#![feature(static_align)]
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = 0;
```
We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`.
r? `@traviscross`
|
|
inclusive `Range`s: change `end` to `last`
Tracking issue: rust-lang/rust#125687
ACP: rust-lang/libs-team#511
|
|
|
|
|
|
|
|
We need a different attribute than `rustc_align` because unstable attributes are
tied to their feature (we can't have two unstable features use the same
unstable attribute). Otherwise this uses all of the same infrastructure
as `#[rustc_align]`.
|
|
|
|
|
|
|
|
fix APITIT being treated as a normal generic parameter in suggestions
closes rust-lang/rust#126395
|
|
Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position
Tracking issue: rust-lang/rust#60210
Closes rust-lang/rust#60210
## Summary
Bump the ["suffixes on a tuple index are invalid" non-lint pseudo future-incompatibility warning (#60210)][issue-60210][^non-lint] to a **hard error** across all editions, rejecting the remaining carve outs from accidentally accepted invalid suffixes since Rust **1.27**.
- We accidentally accepted invalid suffixes in tuple indexing positions in Rust **1.27**. Originally reported at https://github.com/rust-lang/rust/issues/59418.
- We tried to hard reject all invalid suffixes in https://github.com/rust-lang/rust/pull/59421, but unfortunately it turns out there were proc macros accidentally relying on it: https://github.com/rust-lang/rust/issues/60138.
- We temporarily accepted `{i,u}{32,size}` in https://github.com/rust-lang/rust/pull/60186 (the "*carve outs*") to mitigate *immediate* ecosystem impact, but it came with an FCW warning indicating that we wanted to reject it after a few Rust releases.
- Now (1.89.0) is a few Rust releases later (1.35.0), thus I'm proposing to **also reject the carve outs**.
- `std::mem::offset_of!` stabilized in Rust **1.77.0** happens to use the same "don't expect suffix" code path which has the carve outs, so it also accepted the carve out suffixes. I'm proposing to **reject this case as well**.
## What specifically breaks?
Code that still relied on invalid `{i,u}{32,size}` suffixes being temporarily accepted by rust-lang/rust#60186 as an ecosystem impact mitigation measure (cf. rust-lang/rust#60138). Specifically, the following cases (particularly the construction of these forms in proc macros like reported in rust-lang/rust#60138):
### Position 1: Invalid `{i,u}{32,size}` suffixes in tuple indexing
```rs
fn main() {
let _x = (42,).0invalid; // Already error, already rejected by #59421
let _x = (42,).0i8; // Already error, not one of the #60186 carve outs.
let _x = (42,).0usize; // warning: suffixes on a tuple index are invalid
}
```
### Position 2: Invalid `{i,u}{32,size}` suffixes in tuple struct indexing
```rs
fn main() {
struct X(i32);
let _x = X(42);
let _x = _x.0invalid; // Already error, already rejected by #59421
let _x = _x.0i8; // Already error, not one of the #60186 carve outs.
let _x = _x.0usize; // warning: suffixes on a tuple index are invalid
}
```
### Position 3: Invalid `{i,u}{32,size}` suffixes in numeric struct field names
```rs
fn main() {
struct X(i32, i32, i32);
let _x = X(1, 2, 3);
let _y = X { 0usize: 42, 1: 42, 2: 42 }; // warning: suffixes on a tuple index are invalid
match _x {
X { 0usize: 1, 1: 2, 2: 3 } => todo!(), // warning: suffixes on a tuple index are invalid
_ => {}
}
}
```
### Position 4: Invalid `{i,u}{32,size}` suffixes in `std::mem::offset_of!`
While investigating the warning, unfortunately I noticed `std::mem::offset_of!` also happens to use the "expect no suffix" code path which had the carve outs. So this was accepted since Rust **1.77.0** with the same FCW:
```rs
fn main() {
#[repr(C)]
pub struct Struct<T>(u8, T);
assert_eq!(std::mem::offset_of!(Struct<u32>, 0usize), 0);
//~^ WARN suffixes on a tuple index are invalid
}
```
### The above forms in proc macros
For instance, constructions like (see tracking issue rust-lang/rust#60210):
```rs
let i = 0;
quote! { foo.$i }
```
where the user needs to actually write
```rs
let i = syn::Index::from(0);
quote! { foo.$i }
```
### Crater results
Conducted a crater run (https://github.com/rust-lang/rust/pull/145463#issuecomment-3194920383).
- https://github.com/AmlingPalantir/r4/tree/256af3c72f094b298cd442097ef7c571d8001f29: genuine regression; "invalid suffix `usize`" in derive macro. Has a ton of other build warnings, last updated 6 years ago.
- Exactly the kind of intended breakage. Minimized down to https://github.com/AmlingPalantir/r4/blob/256af3c72f094b298cd442097ef7c571d8001f29/validates_derive/src/lib.rs#L71-L75, where when interpolation uses `quote`'s `ToTokens` on a `usize` index (i.e. on tuple struct `Tup(())`), the generated suffix becomes `.0usize` (cf. Position 2).
- Notified crate author of breakage in https://github.com/AmlingPalantir/r4/issues/1.
- Other failures are unrelated or spurious.
## Review remarks
- Commits 1-3 expands the test coverage to better reflect the current situation before doing any functional changes.
- Commit 4 is an intentional **breaking change**. We bump the non-lint "suffixes on a tuple index are invalid" warning into a hard error. Thus, this will need a crater run and a T-lang FCP.
## Tasks
- [x] Run crater to check if anyone is still relying on this being not a hard error. Determine degree of ecosystem breakage.
- [x] If degree of breakage seems acceptable, draft nomination report for T-lang for FCP.
- [x] Determine hard error on Edition 2024+, or on all editions.
## Accompanying Reference update
- https://github.com/rust-lang/reference/pull/1966
[^non-lint]: The FCW was implemented as a *non-lint* warning (meaning it has no associated lint name, and you can't `#![deny(..)]` it) because spans coming from proc macros could not be distinguished from regular field access. This warning was also intentionally impossible to silence. See https://github.com/rust-lang/rust/pull/60186#issuecomment-485581694.
[issue-60210]: https://github.com/rust-lang/rust/issues/60210
|
|
const-eval: disable pointer fragment support
This fixes https://github.com/rust-lang/rust/issues/146291 by disabling pointer fragment support for const-eval. I want to properly fix this eventually, but won't get to it in the next few weeks, so this is an emergency patch to prevent the buggy implementation from landing on stable. The beta cutoff is on Sep 12th so if this PR lands after that, we'll need a backport.
|
