Rustfmt: Better handling of extraneous angle-brackets

Created on 14 Apr 2016  路  4Comments  路  Source: rust-lang/rustfmt

Consider the following code that contains an extraneous set of <>.

fn x(x: HashMap<i64, <i64>>) {}

Instead of warning about the illegal syntax, rustfmt rewrites this to

fn x() {}

To give an even weirder example:

fn x(x: i64, y: HashMap<i64, <i64>>) {}

is rewritten to

fn x(x: i64 /* y: HashMap<i64, <i64>> */) {}

for no good reason as far as I can tell?

bug

Most helpful comment

@marcusklaas I think the point here is that rustfmt should _not_ reformat code which doesn't parse. I.e., we should be giving up, but we don't.

All 4 comments

Hmm, I think what might be happening here and in #915 is that the parser is finding errors, but recovering and rustfmt is assuming that means that we parsed OK and then formats based on the AST it produces.

It should be a fairly easy fix to check for errors after parsing, and terminate in that case.

Whilst this is a strange bug, I think we should keep in mind that rustfmt's focus is to format compiling code.

@marcusklaas that's true, although cases where rustfmt deletes chunks of code are quite disruptive to the development process. I'll have to either retype or undo back to before invoking rustfmt, rather than just fix the error and re-save.

@marcusklaas I think the point here is that rustfmt should _not_ reformat code which doesn't parse. I.e., we should be giving up, but we don't.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Julian-Wollersberger picture Julian-Wollersberger  路  5Comments

reem picture reem  路  5Comments

LPGhatguy picture LPGhatguy  路  3Comments

tkilbourn picture tkilbourn  路  5Comments

Diggsey picture Diggsey  路  4Comments