| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=nagisa
Fix suggesting turbofish with lifetime arguments
Now we suggest turbofish correctly given exprs like `foo<'_>`.
Also fix suggestion when we have `let x = foo<bar, baz>;` which was broken.
|
|
|
|
Swift has specific syntax that desugars to `Option<T>` similar to our
`?` operator, which means that people might try to use it in Rust. Parse
it and gracefully recover.
|
|
|
|
|
|
Lint bare traits in AstConv.
Removing the lint from lowering allows to:
- make lowering querification easier;
- have the lint implementation in only one place.
r? `@estebank`
|
|
|
|
|
|
|
|
Stabilise `feature(const_generics_defaults)`
`feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation.
needs stabilisation report and maybe an RFC :sweat_smile:
r? `@lcnr`
cc `@rust-lang/project-const-generics`
|
|
* Point at RHS of associated type in obligation span
* Point at `impl` assoc type on projection error
* Reduce verbosity of recursive obligations
* Point at source of binding lifetime obligation
* Tweak "required bound" note
* Tweak "expected... found opaque (return) type" labels
* Point at set type in impl assoc type WF errors
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #87599 (Implement concat_bytes!)
- #89999 (Update std::env::temp_dir to use GetTempPath2 on Windows when available.)
- #90796 (Remove the reg_thumb register class for asm! on ARM)
- #91042 (Use Vec extend instead of repeated pushes on several places)
- #91634 (Do not attempt to suggest help for overly malformed struct/function call)
- #91685 (Install llvm tools to sysroot when assembling local toolchain)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Do not attempt to suggest help for overly malformed struct/function call
This fixes: https://github.com/rust-lang/rust/issues/91461
|
|
Rollup of 5 pull requests
Successful merges:
- #91042 (Use Vec extend instead of repeated pushes on several places)
- #91476 (Improve 'cannot contain emoji' error.)
- #91568 (Pretty print break and continue without redundant space)
- #91645 (Implement `core::future::join!`)
- #91666 (update Miri)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve 'cannot contain emoji' error.
Before:
```
error: identifiers cannot contain emoji: `🦀`
--> src/main.rs:2:9
|
2 | let 🦀 = 1;
| ^^
```
After:
```
error: Ferris cannot be used as an identifier
--> src/main.rs:2:9
|
2 | let 🦀 = 1;
| ^^ help: try using their name instead: `ferris`
```
r? `@estebank`
|
|
Add a suggestion if `macro_rules` is misspelled
Fixes #91227.
|
|
|
|
|
|
|
|
There's a few spots where semicolons are checked for to do error recovery,
and should not be suggested (or checked for other stuff).
Fixes #87647
|
|
|
|
Improve diagnostic for missing half of binary operator in `if` condition
Fixes #91421. I've also changed it so that it doesn't consume the `else` token in the error case, because it will try to consume it again afterwards, leading to this incorrect error message (where the `else` reported as missing is actually there):
```
error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
--> src/main.rs:4:12
|
4 | } else { 4 };
| ^ expected one of `.`, `;`, `?`, `else`, or an operator
```
r? `@lcnr`
|
|
|
|
When recovering from a `:` in a pattern, use adequate AST pattern
If the suggestion to use `::` instead of `:` in the pattern isn't correct, a second resolution error will be emitted.
|
|
|
|
Move some tests to more reasonable directories - 10
cc #73494
r? `@petrochenkov`
|
|
|
|
|
|
Tokenize emoji as if they were valid identifiers
In the lexer, consider emojis to be valid identifiers and reject
them later to avoid knock down parse errors.
Partially address #86102.
|
|
|
|
Fix #84946
|
|
|
|
|
|
|
|
|
|
|
|
In the lexer, consider emojis to be valid identifiers and reject
them later to avoid knock down parse errors.
|
|
Point at source of trait bound obligations in more places
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*`).
We no longer point at associated items (`ImplObligation`), as they didn't
add any user actionable information, they just added noise.
Address part of #89418.
|
|
Fix ICE `#90993`: add missing call to cancel
Fix #90993
|
|
|
|
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
|
|
Because the parser directory has already reached the 1000 file limit.
|
|
|
|
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 = `?
|
|
|
|
|
|
|
|
|
|
|
