| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
When encountering an unsatisfied trait bound, if there are no other
suggestions, mention all the types that *do* implement that trait:
```
error[E0277]: the trait bound `f32: Foo` is not satisfied
--> $DIR/impl_wf.rs:22:6
|
LL | impl Baz<f32> for f32 { }
| ^^^^^^^^ the trait `Foo` is not implemented for `f32`
|
= help: the following other types implement trait `Foo`:
Option<T>
i32
str
note: required by a bound in `Baz`
--> $DIR/impl_wf.rs:18:31
|
LL | trait Baz<U: ?Sized> where U: Foo { }
| ^^^ required by this bound in `Baz`
```
Mention implementers of traits in `ImplObligation`s.
Do not mention other `impl`s for closures, ranges and `?`.
|
|
Improve method name suggestions
Attempts to improve method name suggestions when a matching method name
is not found. The approach taken is use the Levenshtein distance and
account for substrings having a high distance but can sometimes be very
close to the intended method (eg. empty vs is_empty).
resolves #94747
|
|
Do not use `ParamEnv::and` when building a cache key from a param-env and trait eval candidate
Do not use `ParamEnv::and` to cache a param-env with a selection/evaluation candidate.
This is because if the param-env is `RevealAll` mode, and the candidate looks global (i.e. it has erased regions, which can show up when we normalize a projection type under a binder<sup>1</sup>), then when we use `ParamEnv::and` to pair the candidate and the param-env for use as a cache key, we will throw away the param-env's caller bounds, and we'll end up caching a candidate that we inferred from the param-env with a empty param-env, which may cause cache-hit later when we have an empty param-env, and possibly mess with normalization like we see in the referenced issue during codegen.
Not sure how to trigger this with a more structured test, but changing `check-pass` to `build-pass` triggers the case that https://github.com/rust-lang/rust/issues/94903 detected.
<sup>1.</sup> That is, we will replace the late-bound region with a placeholder, which gets canonicalized and turned into an infererence variable, which gets erased during region freshening right before we cache the result. Sorry, it's quite a few steps.
Fixes #94903
r? `@Aaron1011` (or reassign as you see fit)
|
|
Don't emit non-asm contents error for naked function composed of errors
## Motivation
For naked functions an error is emitted when they are composed of anything other than a single asm!() block. However, this error triggers in a couple situations in which it adds no additional information or is actively misleading.
One example is if you do have an asm!() block but simply one with a syntax error:
```rust
#[naked]
unsafe extern "C" fn compiler_errors() {
asm!(invalid_syntax)
}
```
This results in two errors, one for the syntax error itself and another telling you that you need an asm block in your function:
```rust
error[E0787]: naked functions must contain a single asm block
--> src/main.rs:6:1
|
6 | / unsafe extern "C" fn naked_compile_error() {
7 | | asm!(blah)
8 | | }
| |_^
```
This issue also comes up when [utilizing `compile_error!()` for improving your diagnostics](https://twitter.com/steveklabnik/status/1509538243020218372), such as raising a compiler error when compiling for an unsupported target.
## Implementation
The rules this PR implements are as follows:
1. If any non-erroneous non-asm statement is included, an error will still occur
2. If multiple asm statements are included, an error will still occur
3. If 0 or 1 asm statements are present, as well as any non-zero number of erroneous statements, then this error will *not* be raised as it is likely either redundant or incorrect
The rule of thumb is effectively "if an error is present and its correction could change things, don't raise an error".
|
|
Attempts to improve method name suggestions when a matching method name
is not found. The approach taken is use the Levenshtein distance and
account for substrings having a high distance but can sometimes be very
close to the intended method (eg. empty vs is_empty).
|
|
Suggest `i += 1` when we see `i++` or `++i`
Closes #83502 (for `i++` and `++i`; `--i` should be covered by #82987, and `i--`
is tricky to handle).
This is a continuation of #83536.
r? `@estebank`
|
|
Rollup of 4 pull requests
Successful merges:
- #95587 (Remove need for associated_type_bounds in std.)
- #95589 (Include a header in .rlink files)
- #95593 (diagnostics: add test case for bogus T:Sized suggestion)
- #95597 (Refer to u8 by absolute path in expansion of thread_local)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Refer to u8 by absolute path in expansion of thread_local
The standard library's `thread_local!` macro previously referred to `u8` just as `u8`, resolving to whatever `u8` existed in the type namespace at the call site. This PR replaces those with `$crate::primitive::u8` which always refers to `std::primitive::u8` regardless of what's in scope at the call site. Unambiguously naming primitives inside macro-generated code is the reason that std::primitive was introduced in the first place.
<details>
<summary>Here is the error message prior to this PR ⬇️</summary>
```console
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| |_^ expected struct `u8`, found integer
|
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| | ^
| | |
| |_expected struct `u8`, found integer
| this expression has type `u8`
|
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| |_^ expected `u8`, found struct `u8`
|
= note: expected raw pointer `*mut u8` (`u8`)
found raw pointer `*mut u8` (struct `u8`)
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| |_^ expected `u8`, found struct `u8`
|
= note: expected fn pointer `unsafe extern "C" fn(*mut u8)`
found fn item `unsafe extern "C" fn(*mut u8) {destroy}`
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0308]: mismatched types
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| | ^
| | |
| |_expected struct `u8`, found integer
| expected due to this type
|
= note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0369]: binary operation `==` cannot be applied to type `u8`
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| | ^
| | |
| |_u8
| {integer}
|
note: an implementation of `PartialEq<_>` might be missing for `u8`
--> src/main.rs:4:1
|
4 | struct u8;
| ^^^^^^^^^^ must implement `PartialEq<_>`
= note: this error originates in the macro `$crate::assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider annotating `u8` with `#[derive(PartialEq)]`
|
4 | #[derive(PartialEq)]
|
error[E0277]: `u8` doesn't implement `Debug`
--> src/main.rs:6:1
|
6 | / std::thread_local! {
7 | | pub static A: i32 = f();
8 | | pub static B: i32 = const { 0 };
9 | | }
| |_^ `u8` cannot be formatted using `{:?}`
|
= help: the trait `Debug` is not implemented for `u8`
= note: add `#[derive(Debug)]` to `u8` or manually `impl Debug for u8`
= note: this error originates in the macro `$crate::assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)
```
</details>
|
|
|
|
Make GATs object safe under generic_associated_types_extended feature
Based on #94869
Let's say we have
```rust
trait StreamingIterator {
type Item<'a> where Self: 'a;
}
```
And `dyn for<'a> StreamingIterator<Item<'a> = &'a i32>`.
If we ask `(dyn for<'a> StreamingIterator<Item<'a> = &'a i32>): StreamingIterator`, then we have to prove that `for<'x> (&'x i32): Sized`. So, we generate *new* bound vars to subst for the GAT generics.
Importantly, this doesn't fully verify that these are usable and sound.
r? `@nikomatsakis`
|
|
|
|
Closes #69228
|
|
ast_lowering: Stop wrapping `ident` matchers into groups
The lowered forms goes to metadata, for example during encoding of macro definitions.
This is a missing part of https://github.com/rust-lang/rust/pull/92472.
Fixes https://github.com/rust-lang/rust/issues/95569
r? `@Aaron1011`
|
|
Fix `thread_local!` macro to be compatible with `no_implicit_prelude`
Fixes issue #95533.
|
|
Add error message suggestion for missing noreturn in naked function
I had to google the syntax for inline asm's `noreturn` option when I got this error earlier today, so I figured I'd save others the trouble and add the syntax/fix as a suggestion in the error.
|
|
invalid_value lint: detect invalid initialization of arrays
|
|
Handle rustc_const_stable attribute in library feature collector
The library feature collector in [compiler/rustc_passes/src/lib_features.rs](https://github.com/rust-lang/rust/blob/551b4fa395fa588d91cbecfb0cdfe1baa02670cf/compiler/rustc_passes/src/lib_features.rs) has only been looking at `#[stable(…)]`, `#[unstable(…)]`, and `#[rustc_const_unstable(…)]` attributes, while ignoring `#[rustc_const_stable(…)]`. The consequences of this were:
- When any const feature got stabilized (changing one or more `rustc_const_unstable` to `rustc_const_stable`), users who had previously enabled that unstable feature using `#![feature(…)]` would get told "unknown feature", rather than rustc's nicer "the feature … has been stable since … and no longer requires an attribute to enable".
This can be seen in the way that https://github.com/rust-lang/rust/pull/93957#issuecomment-1079794660 failed after rebase:
```console
error[E0635]: unknown feature `const_ptr_offset`
--> $DIR/offset_from_ub.rs:1:35
|
LL | #![feature(const_ptr_offset_from, const_ptr_offset)]
| ^^^^^^^^^^^^^^^^
```
- We weren't enforcing that a particular feature is either stable everywhere or unstable everywhere, and that a feature that has been stabilized has the same stabilization version everywhere, both of which we enforce for the other stability attributes.
This PR updates the library feature collector to handle `rustc_const_stable`, and fixes places in the standard library and test suite where `rustc_const_stable` was being used in a way that does not meet the rules for a stability attribute.
|
|
The lowered forms goes to metadata, for example during encoding of macro definitions
|
|
|
|
|
|
|
|
|
|
Fixes issue #95533
|
|
interpret: make isize::MAX the limit for dynamic value sizes
We are currently enforcing `data_layout.obj_size_bound()` as the maximal dynamic size of a Rust value (including for `size_of_val_raw`), but that does not match the docs.
In particular, Miri currently falsely says that this code has UB:
```rust
#![feature(layout_for_ptr)]
fn main() {
let size = isize::MAX as usize;
// Creating a raw slice of size isize::MAX and asking for its size is okay.
let s = std::ptr::slice_from_raw_parts(1usize as *const u8, size);
assert_eq!(size, unsafe { std::mem::size_of_val_raw(s) });
}
```
|
|
suggest wrapping single-expr blocks in square brackets
Suggests a fix in cases like:
```diff
- const A: [i32; 1] = { 1 };
+ const A: [i32; 1] = [ 1 ];
^ ^
```
Also edit the message for the same suggestion in the parser (e.g. `{ 1, 2 }`).
Fixes #95289
|
|
Better suggestions for `Fn`-family trait selection errors
1. Suppress suggestions to add `std::ops::Fn{,Mut,Once}` bounds when a type already implements `Fn{,Mut,Once}`
2. Add a note that points out that a type does in fact implement `Fn{,Mut,Once}`, but the arguments vary (either by number or by actual arguments)
3. Add a note that points out that a type does in fact implement `Fn{,Mut,Once}`, but not the right one (e.g. implements `FnMut`, but `Fn` is required).
Fixes #95147
|
|
|
|
|
|
Specialize infinite-type "insert some indirection" suggestion for Option
Suggest `Option<Box<_>>` instead of `Box<Option<_>>` for infinitely-recursive members of a struct.
Not sure if I can get the span of the generic subty of the Option so I can make this a `+++`-style suggestion. The current output is a tiny bit less fancy looking than the original suggestion.
Should I limit the specialization to just `Option<Box<TheOuterStruct>>`? Because right now it applies to all `Option` members in the struct that are returned by `Representability::SelfRecursive`.
Fixes #91402
r? `@estebank`
(since you wrote the original suggestion and are definitely most familiar with it!)
|
|
|
|
|
|
|
|
|
|
r=compiler-errors
Add note to the move size diagnostic
context: https://github.com/rust-lang/rust/issues/83518
|
|
Don't ICE when opaque types get their hidden type constrained again.
Contrary to popular belief, `codegen_fulfill_obligation` does not get used solely in codegen, so we cannot rely on `param_env` being set to RevealAll and thus revealing the hidden types instead of constraining them.
Fixes #89312 (for real this time)
|
|
Restore `impl Future<Output = Type>` to async blocks
I was sad when I undid some of the code I wrote in #91096 in the PR #95225, so I fixed it here to not print `[async output]`.
This PR "manually" normalizes the associated type `<[generator] as Generator>::Return` type which appears very frequently in `impl Future` types that result from async block desugaring.
|
|
|
|
Add the generic_associated_types_extended feature
Right now, this only ignore obligations that reference new placeholders in `poly_project_and_unify_type`. In the future, this might do other things, like allowing object-safe GATs.
**This feature is *incomplete* and quite likely unsound. This is mostly just for testing out potential future APIs using a "relaxed" set of rules until we figure out *proper* rules.**
Also drive by cleanup of adding a `ProjectAndUnifyResult` enum instead of using a `Result<Result<Option>>`.
r? `@nikomatsakis`
|
|
Stabilize native library modifier syntax and the `whole-archive` modifier specifically
Stabilization report: https://github.com/rust-lang/rust/pull/93901#issuecomment-1041325522
cc https://github.com/rust-lang/rust/issues/81490
|
|
|
|
specifically
|
|
r=petrochenkov
Yet more `parse_tt` improvements
Including lots of comment improvements, and an overhaul of how `matches` work that gives big speedups.
r? `@petrochenkov`
|
|
|
|
Contrary to popular belief, `codegen_fulfill_obligation` does not get used solely in codegen, so we cannot rely on `param_env` being set to RevealAll and thus revealing the hidden types instead of constraining them.
|
|
allow arbitrary inherent impls for builtin types in core
Part of https://github.com/rust-lang/compiler-team/issues/487. Slightly adjusted after some talks with `@m-ou-se` about the requirements of `t-libs-api`.
This adds a crate attribute `#![rustc_coherence_is_core]` which allows arbitrary impls for builtin types in core.
For other library crates impls for builtin types should be avoided if possible. We do have to allow the existing stable impls however. To prevent us from accidentally adding more of these in the future, there is a second attribute `#[rustc_allow_incoherent_impl]` which has to be added to **all impl items**. This only supports impls for builtin types but can easily be extended to additional types in a future PR.
This implementation does not check for overlaps in these impls. Perfectly checking that requires us to check the coherence of these incoherent impls in every crate, as two distinct dependencies may add overlapping methods. It should be easy enough to detect if it goes wrong and the attribute is only intended for use inside of std.
The first two commits are mostly unrelated cleanups.
|
|
|
|
|
