Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unhelpful error message when missing the final path segment for a function call #120892

Closed
Jarcho opened this issue Feb 10, 2024 · 5 comments · Fixed by #122152
Closed

Unhelpful error message when missing the final path segment for a function call #120892

Jarcho opened this issue Feb 10, 2024 · 5 comments · Fixed by #122152
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST. D-confusing Diagnostics: Confusing error or lint that should be reworked. D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Jarcho
Copy link
Contributor

Jarcho commented Feb 10, 2024

Given an invalid call such as:

fn main() {
  foo::("foo");
}

The following diagnostic is issued:

error: expected type, found `"foo"`
 --> src/main.rs:2:9
  |
2 |   foo::("foo");
  |         ^^^^^ expected type

This gets much worse on multiline calls:

fn main() {
  foo::(
    bar(x, y, z),
    bar(x, y, z),
    bar(x, y, z),
    bar(x, y, z),
    bar(x, y, z),
    bar(x, y, z),
    bar(x, y, z),
    baz("test"),
  ),
}

Which just prints out a diagnostic nowhere near the error:

error: expected type, found `"test"`
  --> src/main.rs:10:13
   |
10 |         baz("test"),
   |             ^^^^^^ expected type

Ideally this should mention something about either missing a missing turbofish (e.g. foo::<..>("foo")), or a missing identifier (e.g. foo::bar("foo")). This would at least get the error pointing to the correct spot.


Latest playground nightly (2024-02-09)

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Feb 10, 2024
@fmease fmease added A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. D-confusing Diagnostics: Confusing error or lint that should be reworked. D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. A-parser Area: The parsing of Rust source code to an AST. labels Feb 10, 2024
@fmease
Copy link
Member

fmease commented Feb 10, 2024

Oh, wow, it didn't even occur to me until now that the expression Option::(i32)::None::() is syntactically valid >.<

Edit: Wow, even let _ = Fn::() -> Option<i32>; is syntactically well-formed.

@fmease
Copy link
Member

fmease commented Feb 10, 2024

This should pretty easy to fix, basically if we fail to parse a type here

let (inputs, _) = self.parse_paren_comma_seq(|p| p.parse_ty())?;

we should first of all attach a label to the ::( saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the PathStyle is Expr, the parenthesized generics aren't followed by :: or -> and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser).

Furthermore, if the PathStyle is Pat we can try to reparse the list as a list of patterns and provide the same structured suggestion.

I will gladly mentor & review any PR for this.

@fmease fmease added the E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. label Feb 10, 2024
@SummerGram
Copy link

@rustbot claim

@fmease fmease self-assigned this Mar 2, 2024
@wutchzone
Copy link
Contributor

Hello @fmease , is this issue still open for mentoring? I can see that @SummerGram already claimed the issue, but there seems to be no progress.

@SummerGram
Copy link

@wutchzone

I read the code but no time to finish it at the moment. You can do it.

@fmease fmease assigned wutchzone and unassigned SummerGram Mar 3, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 9, 2024
Improve diagnostics for parenthesized type arguments

Fixes rust-lang#120892

r? fmease
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 11, 2024
Improve diagnostics for parenthesized type arguments

Fixes rust-lang#120892

r? fmease
@bors bors closed this as completed in 05ff86c Mar 11, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 11, 2024
Rollup merge of rust-lang#122152 - wutchzone:120892, r=fmease

Improve diagnostics for parenthesized type arguments

Fixes rust-lang#120892

r? fmease
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST. D-confusing Diagnostics: Confusing error or lint that should be reworked. D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants