| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Keep spans for generics in `#[derive(_)]` desugaring
Keep the spans for generics coming from a `derive`d Item, so that errors
and suggestions have better detail.
Fix #84003.
|
|
Reintroduce `into_future` in `.await` desugaring
This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet.
This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions, so we need to make sure this does not introduce those issues again.
Issues #67644, #67982
/cc `@yoshuawuyts`
|
|
|
|
Keep the spans for generics coming from a `derive`d Item, so that errors
and suggestions have better detail.
Fix #84003.
|
|
|
|
Diagnostic tweaks
* On type mismatch caused by assignment, point at the source of the expectation
* Hide redundant errors
* Suggest `while let` when `let` is missing in some cases
|
|
* Do not emit unnecessary E0308 after E0070
* Show fewer errors on `while let` missing `let`
* Hide redundant E0308 on `while let` missing `let`
* Point at binding definition when possible on invalid assignment
* do not point at closure twice
* do not suggest `if let` for literals in lhs
* account for parameter types
|
|
|
|
|
|
|
|
Be more thorough in using `ItemObligation` and `BindingObligation` when
evaluating obligations so that we can point at trait bounds that
introduced unfulfilled obligations. We no longer incorrectly point at
unrelated trait bounds (`substs-ppaux.verbose.stderr`).
In particular, we now point at trait bounds on method calls.
We no longer point at "obvious" obligation sources (we no longer have a
note pointing at `Trait` saying "required by a bound in `Trait`", like
in `associated-types-no-suitable-supertrait*`).
Address part of #89418.
|
|
Elaborate `Future::Output` when printing opaque `impl Future` type
I would love to see the `Output =` type when printing type errors involving opaque `impl Future`.
[Test code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a800b481edd31575fbcaf5771a9c3678)
Before (cut relevant part of output):
```
note: while checking the return type of the `async fn`
--> /home/michael/test.rs:5:19
|
5 | async fn bar() -> usize {
| ^^^^^ checked the `Output` of this `async fn`, found opaque type
= note: expected type `usize`
found opaque type `impl Future`
```
After:
```
note: while checking the return type of the `async fn`
--> /home/michael/test.rs:5:19
|
5 | async fn bar() -> usize {
| ^^^^^ checked the `Output` of this `async fn`, found opaque type
= note: expected type `usize`
found opaque type `impl Future<Output = usize>`
```
Note the "found opaque type `impl Future<Output = usize>`" in the new output.
----
Questions:
1. We skip printing the output type when it's a projection, since I have been seeing some types like `impl Future<Output = <[static generator@/home/michael/test.rs:2:11: 2:21] as Generator<ResumeTy>>::Return>` which are not particularly helpful and leak implementation detail.
* Am I able to normalize this type within `rustc_middle::ty::print::pretty`? Alternatively, can we normalize it when creating the diagnostic? Otherwise, I'm fine with skipping it and falling back to the old output.
* Should I suppress any other types? I didn't encounter anything other than this generator projection type.
2. Not sure what the formatting of this should be. Do I include spaces in `Output = `?
|
|
Improve suggestions for compatible variants on type mismatch.
Fixes #90553.
Before:
After:
r? `````@estebank`````
|
|
|
|
notriddle:notriddle/rustc-suggest-float-ending-in-dot, r=sanxiyn
Avoid suggesting literal formatting that turns into member access
Fixes #90974
|
|
Fixes #90974
|
|
|
|
|
|
check where-clause for explicit `Sized` before suggesting `?Sized`
Fixes #85945.
Based on #86454.
``@rustbot`` label +A-diagnostics +A-traits +A-typesystem +D-papercut +T-compiler
|
|
|
|
|
|
pub use core::simd;
A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust, `std::arch` offers explicit SIMD acceleration via compiler intrinsics, but it does so at the cost of having to individually maintain each and every single such API, and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation, including scalar instructions if that is all that is available.
`core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets, features, and optimizations produce the same result, so that using this library does not introduce any surprises. As these tests are technically non-deterministic, and thus can introduce overly interesting Heisenbugs if included in the rustc CI, they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation, but these use deterministic asserts.
There are multiple unsolved problems with the library at the current moment, including a want for better documentation, technical issues with LLVM scalarizing and lowering to libm, room for improvement for the APIs, and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However, I thought it would be prudent to open this for review in its current condition, as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out.
The major types are
- `core::simd::Simd<T, N>`
- `core::simd::Mask<T, N>`
There is also the `LaneCount` struct, which, together with the SimdElement and SupportedLaneCount traits, limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.
|
|
This enables programmers to use a safe alternative to the current
`extern "platform-intrinsics"` API for writing portable SIMD code.
This is `#![feature(portable_simd)]` as tracked in #86656
|
|
Suggest dereference of `Box` when inner type is expected
For example:
enum Ty {
Unit,
List(Box<Ty>),
}
fn foo(x: Ty) -> Ty {
match x {
Ty::Unit => Ty::Unit,
Ty::List(elem) => foo(elem),
}
}
Before, the only suggestion was to rewrap `inner` with `Ty::Wrapper`,
which is unhelpful and confusing:
error[E0308]: mismatched types
--> src/test/ui/suggestions/boxed-variant-field.rs:9:31
|
9 | Ty::List(elem) => foo(elem),
| ^^^^
| |
| expected enum `Ty`, found struct `Box`
| help: try using a variant of the expected enum: `Ty::List(elem)`
|
= note: expected enum `Ty`
found struct `Box<Ty>`
Now, rustc will first suggest dereferencing the `Box`, which is most
likely what the user intended:
error[E0308]: mismatched types
--> src/test/ui/suggestions/boxed-variant-field.rs:9:31
|
9 | Ty::List(elem) => foo(elem),
| ^^^^ expected enum `Ty`, found struct `Box`
|
= note: expected enum `Ty`
found struct `Box<Ty>`
help: try dereferencing the `Box`
|
9 | Ty::List(elem) => foo(*elem),
| +
help: try using a variant of the expected enum
|
9 | Ty::List(elem) => foo(Ty::List(elem)),
| ~~~~~~~~~~~~~~
r? ``@davidtwco``
|
|
For example:
enum Ty {
Unit,
List(Box<Ty>),
}
fn foo(x: Ty) -> Ty {
match x {
Ty::Unit => Ty::Unit,
Ty::List(elem) => foo(elem),
}
}
Before, the only suggestion was to rewrap `elem` with `Ty::List`,
which is unhelpful and confusing:
error[E0308]: mismatched types
--> src/test/ui/suggestions/boxed-variant-field.rs:9:31
|
9 | Ty::List(elem) => foo(elem),
| ^^^^
| |
| expected enum `Ty`, found struct `Box`
| help: try using a variant of the expected enum: `Ty::List(elem)`
|
= note: expected enum `Ty`
found struct `Box<Ty>`
Now, rustc will first suggest dereferencing the `Box`, which is most
likely what the user intended:
error[E0308]: mismatched types
--> src/test/ui/suggestions/boxed-variant-field.rs:9:31
|
9 | Ty::List(elem) => foo(elem),
| ^^^^ expected enum `Ty`, found struct `Box`
|
= note: expected enum `Ty`
found struct `Box<Ty>`
help: try dereferencing the `Box`
|
9 | Ty::List(elem) => foo(*elem),
| +
help: try using a variant of the expected enum
|
9 | Ty::List(elem) => foo(Ty::List(elem)),
| ~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
getting inconsistent output between local and CI.
|
|
is suggested
|
|
other test
|
|
Fixes #90101
|
|
Point at overlapping impls when type annotations are needed
Address https://github.com/rust-lang/rust/issues/89254.
|
|
|
|
|
|
Revert #86011 to fix an incorrect bound check
This reverts commit 36a1076d24697621a3bb67ef654b4eb79647aa54, reversing
changes made to e1e9319d93aea755c444c8f8ff863b0936d7a4b6.
Fixes #89935
r? ``@estebank``
|
|
Remove redundant member-constraint check
impl trait will, for each lifetime in the hidden type, register a "member constraint" that says the lifetime must be equal or outlive one of the lifetimes of the impl trait. These member constraints will be solved by borrowck
But, as you can see in the big red block of removed code, there was an ad-hoc check for member constraints happening at the site where they get registered. This check had some minor effects on diagnostics, but will fall down on its feet with my big type alias impl trait refactor. So we removed it and I pulled the removal out into a (hopefully) reviewable PR that works on master directly.
|
|
This reverts commit 36a1076d24697621a3bb67ef654b4eb79647aa54, reversing
changes made to e1e9319d93aea755c444c8f8ff863b0936d7a4b6.
|
|
Some "parenthesis" and "parentheses" fixes
"Parenthesis" is the singular (e.g. one `(` or one `)`) and "parentheses" is the plural (multiple `(` or `)`s) and this is not hard to mix up so here are some fixes for that.
Inspired by #89958
|
|
|
|
Remove trailing semicolon from macro call span
Macro call site spans are now less surprising/more consistent since they no longer contain a semicolon after the macro call.
The downside is that we need to do a little guesswork to get the semicolon in diagnostics. But this should not be noticeable since it is rare for the semicolon to not immediately follow the macro call.
|
|
|
|
|
|
Suggest Box::pin when Pin::new is used instead
This fixes an incorrect diagnostic.
**Based on #89390**; only the last commit is specific to this PR. "Ignore whitespace changes" also helps here.
|
|
move implicit `Sized` predicate to end of list
In `Bounds::predicates()`, move the implicit `Sized` predicate to the
end of the generated list. This means that if there is an explicit
`Sized` bound, it will be checked first, and any resulting
diagnostics will have a more useful span.
Fixes #85998, at least partially. ~~Based on #85979, but only the last 2 commits are new for this pull request.~~ (edit: rebased) A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit `Sized` predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter.
I could use some help interpreting the changes to the stderr output. It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with `Sized` bounds. Possibly some error reporting code is making assumptions about ordering of predicates? The diagnostics for src/test/ui/derives/derives-span-Hash-*.rs seem to have improved, no longer pointing at the type parameter identifier, but src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs became less verbose for some reason.
I also ran into an instance of #84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful.
``@estebank`` this seems likely to conflict (slightly?) with your work on #85947; how would you like to resolve that?
|
|
Fix incorrect Box::pin suggestion
The suggestion checked if `Pin<Box<T>>` could be coeerced to the expected
type, but did not check predicates created by the coercion. We now
look for predicates that definitely cannot be satisfied before giving
the suggestion.
The suggestion is still marked MaybeIncorrect because we allow predicates that
are still ambiguous and can't be proven.
Fixes #72117.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #89347 (suggestion for typoed crate or module)
- #89670 (Improve `std::thread::available_parallelism` docs)
- #89757 (Use shallow clones for submodules)
- #89759 (Assemble the compiler when running `x.py build`)
- #89846 (Add `riscv32imc-esp-espidf` to 1.56 changelog)
- #89853 (Update the 1.56.0 release header for consistency)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
