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?
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.
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.