Suggest fix for misplaced generic params on fn item #103366fixes#103366
This still has some work to go, but works for 2/3 of the initial base cases described in #1033366
simple fn:
```
error: expected identifier, found `<`
--> shreys/test_1.rs:1:3
|
1 | fn<T> id(x: T) -> T { x }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn id<T>(x: T) -> T { x }
| ~~~~
```
Complicated bounds
```
error: expected identifier, found `<`
--> spanishpear/test_2.rs:1:3
|
1 | fn<'a, B: 'a + std::ops::Add<Output = u32>> f(_x: B) { }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn f<'a, B: 'a + std::ops::Add<Output = u32>>(_x: B) { }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Opening a draft PR for comments on approach, particularly I have the following questions:
- [x] Is it okay to be using `err.span_suggestion` over struct derives? I struggled to get the initial implementation (particularly the correct suggestion message) on struct derives, although I think given what I've learned since starting, I could attempt re-doing it with that approach.
- [x] in the case where the snippet cannot be obtained from a span, is the `help` but no suggestion okay? I think yes (also, when does this case occur?)
- [x] are there any red flags for the generalisation of this work for relevant item kinds (i.e. `struct`, `enum`, `trait`, and `union`). My basic testing indicates it does work for those types except the help tip is currently hardcoded to `after the function name` - which should change dependent on the item.
- [x] I am planning to not show the suggestion if there is already a `<` after the item identifier, (i.e. if there are already generics, as after a function name per the original issue). Any major objections?
- [x] Is the style of error okay? I wasn't sure if there was a way to make it display nicer, or if thats handled by span_suggestion
These aren't blocking questions, and I will keep working on:
- check if there is a `<` after the ident (and if so, not showing the suggestion)
- generalize the help message
- figuring out how to write/run/etc ui tests (including reading the docs for them)
- logic cleanups
Update cargo
10 commits in 82c3bb79e3a19a5164e33819ef81bfc2c984bc56..39c13e67a5962466cc7253d41bc1099bbcb224c3 2023-02-04 22:52:16 +0000 to 2023-02-12 02:01:08 +0000
- chore: Update to toml v0.6, toml_edit v0.18 (rust-lang/cargo#11618)
- doc: more doc comments and intra-doc links (rust-lang/cargo#11703)
- Deny warnings in CI, not locally (rust-lang/cargo#11699)
- add comment to lto.rs (rust-lang/cargo#11701)
- Re-export cargo_new::NewProjectKind as public (rust-lang/cargo#11700)
- Add '-C' flag for changing current dir before build (rust-lang/cargo#10952)
- `-Zrustdoc-scrape-example` must fail with bad build script (rust-lang/cargo#11694)
- Update CHANGELOG for 1.68 backports (rust-lang/cargo#11690)
- Update 1password to the version 2 CLI (rust-lang/cargo#11692)
- chore: autolabel more for `A-*` (rust-lang/cargo#11679)
r? `@ghost`
Rollup of 8 pull requests
Successful merges:
- #107902 (fix: improve the suggestion on future not awaited)
- #107913 (Update broken link in cargo style guide)
- #107942 (Tighter spans for bad inherent `impl` self types)
- #107948 (Allow shortcuts to directories to be used for ./x.py fmt)
- #107971 (Clearly document intentional UB in mir-opt tests)
- #107985 (Added another error to be processed in fallback)
- #108002 (Update books)
- #108013 (rustdoc: use a string with one-character codes for search index types)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Added another error to be processed in fallback
This pull request addresses the problem of Rust not being able to read file/directory metadata because the current user doesn't have permission to read the file and are thus inaccessible.
One particular example is `System Volume Information`. But any example can be made by having a file/directory, which the current user can't access even though the system does allow to view the metadata, which is handled by the fallback.
The fallback exists to get the metadata but it was limited to one error type. Having added ERROR_ACCESS_DENIED per Chris Denton's suggestion, file/directory properties are now properly read.
Solution suggested by Chris Denton https://github.com/nushell/nushell/issues/6857#issuecomment-1426847135
Clearly document intentional UB in mir-opt tests
All of the changed mir-opt test input files did not pass Miri. Now they do.
r? `@cjgillot` because there's a CopyProp test in here that I do not fully understand
Allow shortcuts to directories to be used for ./x.py fmt
Fixes#107944.
Maximum recursive search depth is 3 and only accepts shortcuts for directories. If there are no shortcut candidates, the previous behavior to panic is preserved. If there are multiple candidates, the shortcut candidates are ignored.
After this change, `./x.py fmt std` no longer panics and formats `library/std` instead.
Update broken link in cargo style guide
Toml now uses [toml.io](https://toml.io) for released specifications and the github repo for development. Also the old link was for the 0.4 specification, while cargo uses toml_edit, which uses toml 1.0 (reference:
https://github.com/toml-rs/toml/blob/main/crates/toml_edit/CHANGELOG.md#030---2021-09-13). Finally the discussion of "Bare keys" vs "Quoted keys" has moved from the `#table` section to `#keys`.
fix: improve the suggestion on future not awaited
Considering the following code
```rust
fn foo() -> u8 {
async fn async_fn() -> u8 { 22 }
async_fn()
}
fn main() {}
```
the error generated before this commit from the compiler is
```
➜ rust git:(macros/async_fn_suggestion) ✗ rustc test.rs --edition 2021
error[E0308]: mismatched types
--> test.rs:4:5
|
1 | fn foo() -> u8 {
| -- expected `u8` because of return type
...
4 | async_fn()
| ^^^^^^^^^^ expected `u8`, found opaque type
|
= note: expected type `u8`
found opaque type `impl Future<Output = u8>`
help: consider `await`ing on the `Future`
|
4 | async_fn().await
| ++++++
error: aborting due to previous error
```
In this case the error is nor perfect, and can confuse the user that do not know that the opaque type is the future.
So this commit will propose (and conclude the work start in https://github.com/rust-lang/rust/issues/80658)
to change the string `opaque type` to `future` when applicable and also remove the Expected vs Received note by adding a more specific one regarding the async function that return a future type.
So the new error emitted by the compiler is
```
error[E0308]: mismatched types
--> test.rs:4:5
|
1 | fn foo() -> u8 {
| -- expected `u8` because of return type
...
4 | async_fn()
| ^^^^^^^^^^ expected `u8`, found future
|
note: calling an async function returns a future
--> test.rs:4:5
|
4 | async_fn()
| ^^^^^^^^^^
help: consider `await`ing on the `Future`
|
4 | async_fn().await
| ++++++
error: aborting due to previous error
```
Fixes https://github.com/rust-lang/rust/issues/80658
It remains to rework the case described in the following issue https://github.com/rust-lang/rust/issues/107899 but I think this deserves its own PR after we discuss a little bit how to handle these kinds of cases.
r? `@eholk`
`@rustbot` label +I-async-nominated
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Fixes#107944.
Maximum recursive search depth is 3 and only accepts shortcuts for
directories (single component paths, such as `./x.py fmt std`). If
there are no shortcut candidates but single componenet path(s) are
given, it falls back to the previous behavior to panic with unable to
find directory. If there are multiple shortcut candidates for a given
single component path, the shortcut candidates are considered
ambiguous, are then ignored, and the single component path is accepted
as-is.
After this change, `./x.py fmt std` no longer panics and formats
`library/std` instead.
Move folding & visiting traits into type library
This is a rework of #107712, following feedback on that PR.
In particular, this version uses trait aliases to reduce the API churn for trait consumers. Doing so requires a workaround for #107747 until its fix in #107803 is merged into the stage0 compiler; this workaround, which uses conditional compilation based on the `bootstrap` configuration predicate, sits in dedicated commit b409329c for ease of reversion.
The possibility of the `rustc_middle` crate retaining its own distinct versions of each folding/visiting trait, blanket-implemented on all types that implement the respective trait in the type library, was also explored: however since this would necessitate making each `rustc_middle` trait a subtrait of the respective type library trait (so that such blanket implementations can delegate their generic methods), no benefit would be gained.
r? types
Considering the following code
```rust
fn foo() -> u8 {
async fn async_fn() -> u8 { 22 }
async_fn()
}
fn main() {}
```
the error generated before this commit from the compiler is
```
➜ rust git:(macros/async_fn_suggestion) ✗ rustc test.rs --edition 2021
error[E0308]: mismatched types
--> test.rs:4:5
|
1 | fn foo() -> u8 {
| -- expected `u8` because of return type
...
4 | async_fn()
| ^^^^^^^^^^ expected `u8`, found opaque type
|
= note: expected type `u8`
found opaque type `impl Future<Output = u8>`
help: consider `await`ing on the `Future`
|
4 | async_fn().await
| ++++++
error: aborting due to previous error
```
In this case the error is nor perfect, and can confuse the user
that do not know that the opaque type is the future.
So this commit will propose (and conclude the work start in
https://github.com/rust-lang/rust/issues/80658)
to change the string `opaque type` to `future` when applicable
and also remove the Expected vs Received note by adding a more
specific one regarding the async function that return a future type.
So the new error emitted by the compiler is
```
error[E0308]: mismatched types
--> test.rs:4:5
|
1 | fn foo() -> u8 {
| -- expected `u8` because of return type
...
4 | async_fn()
| ^^^^^^^^^^ expected `u8`, found future
|
note: calling an async function returns a future
--> test.rs:4:5
|
4 | async_fn()
| ^^^^^^^^^^
help: consider `await`ing on the `Future`
|
4 | async_fn().await
| ++++++
error: aborting due to previous error
```
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Rollup of 6 pull requests
Successful merges:
- #107340 (rustdoc: merge doctest tooltip with notable traits tooltip)
- #107838 (Introduce `-Zterminal-urls` to use OSC8 for error codes)
- #107922 (Print disk usage in PGO CI script)
- #107931 (Intern span when length is MAX_LEN with parent.)
- #107935 (rustc_ast: Merge impls and reorder methods for attributes and meta items)
- #107986 (layout: deal with placeholders, ICE on bound types)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fix: don't include `r#` prefix in filesystem changes
Fixes#14131
In addition to fix for #14131, this PR adds raw ident validity checks in rename functionality that we've been missing.
layout: deal with placeholders, ICE on bound types
A placeholder type is the same as a param as they represent "this could be any type". A bound type represents a type inside of a `for<T>` or `exists<T>`. When entering a forall or exists `T` should be instantiated as a existential (inference var) or universal (placeholder). You should never observe a bound variable without its binder.
rustc_ast: Merge impls and reorder methods for attributes and meta items
Merge `impl` blocks for the same types, change order of methods to be more predictable and consistent between impls.
No functional changes.
Follow up to https://github.com/rust-lang/rust/pull/107569.
Introduce `-Zterminal-urls` to use OSC8 for error codes
Terminals supporting the OSC8 Hyperlink Extension can support inline anchors where the text is user defineable but clicking on it opens a browser to a specified URLs, just like `<a href="URL">` does in HTML.
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
