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

Continue parsing after parent type args and suggest using angle brackets #57768

Merged
merged 4 commits into from Jan 21, 2019

Conversation

Projects
None yet
4 participants
@estebank
Copy link
Contributor

estebank commented Jan 20, 2019

error[E0214]: parenthesized parameters may only be used with a trait
--> $DIR/E0214.rs:2:15
   |
LL |     let v: Vec(&str) = vec!["foo"];
   |               ^^^^^^
   |               |
   |               only traits may use parentheses
   |               help: use angle brackets instead: `<&str>`

r? @zackmdavis

.emit();
(hir::GenericArgs::none(), true)
let mut err = struct_span_err!(self.sess, data.span, E0214, "{}", msg);
err.span_label(data.span, "only traits may use parentheses");

This comment has been minimized.

@zackmdavis

zackmdavis Jan 20, 2019

Member

No time to dig into it now, but I'm mildly curious about the history of this rule. Offhand, I don't seem to recall seeing traits use parentheses for type argum—oh, never mind, I just read --explain 214, and it points out that it's for Fn(T) types.

This does seem sufficiently remote from the crux of the error at hand that we might want to reword the top-line error message to emphasize "parameters use brackets, generally" rather than highlighting the unusual case of traits? I don't have a crisp alternative wording to propose at the moment, though.

Show resolved Hide resolved src/librustc/hir/lowering.rs
@zackmdavis

This comment has been minimized.

Copy link
Member

zackmdavis commented Jan 20, 2019

@estebank My only suggestion is, can we check if GenericArgs::Parenthesized data.inputs is empty and avoid suggesting the empty parameter list <>? I won't insist on it if it's too annoying or too much complexity for a rare case, so r=me

@estebank

This comment has been minimized.

Copy link
Contributor Author

estebank commented Jan 20, 2019

My only suggestion is, can we check if GenericArgs::Parenthesized data.inputs is empty and avoid suggesting the empty parameter list <>?

It makes sense to do so and should be easy enough to add.

I won't insist on it if it's too annoying or too much complexity for a rare case

I feel this is already quite a rare case to begin with, we might as well do it right :)

@estebank estebank force-pushed the estebank:type-args-sugg branch from 89e2825 to 2ab6cef Jan 20, 2019

@estebank

This comment has been minimized.

Copy link
Contributor Author

estebank commented Jan 20, 2019

@bors r=zackmdavis

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 20, 2019

📌 Commit 2ab6cef has been approved by zackmdavis

Centril added a commit to Centril/rust that referenced this pull request Jan 21, 2019

Rollup merge of rust-lang#57768 - estebank:type-args-sugg, r=zackmdavis
Continue parsing after parent type args and suggest using angle brackets

```
error[E0214]: parenthesized parameters may only be used with a trait
--> $DIR/E0214.rs:2:15
   |
LL |     let v: Vec(&str) = vec!["foo"];
   |               ^^^^^^
   |               |
   |               only traits may use parentheses
   |               help: use angle brackets instead: `<&str>`
```

r? @zackmdavis

bors added a commit that referenced this pull request Jan 21, 2019

Auto merge of #57792 - Centril:rollup, r=Centril
Rollup of 5 pull requests

Successful merges:

 - #56796 (Change bounds on `TryFrom` blanket impl to use `Into` instead of `From`)
 - #57768 (Continue parsing after parent type args and suggest using angle brackets)
 - #57769 (Suggest correct cast for struct fields with shorthand syntax)
 - #57783 (Add "dereference boxed value" suggestion.)
 - #57784 (Add span for bad doc comment)

Failed merges:

r? @ghost

@bors bors merged commit 2ab6cef into rust-lang:master Jan 21, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment