Rustfmt command returns an error despite problematic file being ignored and hide_parse_errors is true

[maplant]

I have a problematic file that is not able to be parsed. The reason for that is I'm autogenerating symbol names with macros, in a manner that looks like this:

#[no_mangle]
extern "system" fn jni_symbol!( funcName ) ( ... ) -> {} 

Rustfmt is failing to parse this at the token !, but the larger issue is that I'm failing rusty-hooks despite this file being put into ignore, hide_parse_errors being set to true and no error being emitted and rustfmt seemingly handling every other file just fine. I know that this file is the one that is causing issues because commenting it out results in rustfmt returning 0 as it should

[calebcartwright]

hey @maplant - what happens if you change hide_parse_errors to false in your config and keep that file listed under ignore? I added a change a while back to handle recoverable parser errors in ignored files, but I think I have a theory why this is happening and believe it's related to hide_parse_errors being set to true

[maplant]

@calebcartwright the same effect is observed for me

[calebcartwright]

The underlying problem is that the parser is hitting a fatal error on your snippet, and is unable to create the ast. As such rustfmt is unable to start formatting and exits with an error as well.

In instances where the parser encounters errors, but was still able to recover and construct the ast, rustfmt is able to start formatting and will not exit with an error if all the parser errors (or formatting errors of course) originated in an ignored file.

In your case, rustfmt returning an error code in the presence of that unparseable snippet is expected because rustfmt needs the ast to be able to format the code. How are you running rustfmt in your project, are you using cargo fmt or running rustfmt directly against specified files?

Related aside, there's a couple minor improvements we should make on the rustfmt side anyway (@topecongiro I'll start working on these shortly)

• should still emit the error when the associated DB level is Fatal (unless hide_parse_errors is true), regardless of whether the source file is ignored since the parser won't be able to give rustfmt the ast anyway. Otherwise the fatal parser error text is suppressed but rustfmt will still exit with an error.
• even when hide_parse_errors is true, the associated emitter should include the same logic checks to see if DB source file origin was in an ignored file so that the same error reset logic can be used to ignore the recoverable parser errors

[maplant]

I am using cargo fmt to run rustfmt.
I understand that this is producing an error, if I remove the file from ignored it prints the error.

I would claim that it is unexpected behavior to create an error condition for being unable to build the AST for an ignored file. If the file is ignored, why is it being parsed at all?

Edit: maybe I should say this is unexpected behavior from cargo fmt. If rustfmt were being run individually on this file I believe the error condition is valid

[calebcartwright]

If the file is ignored, why is it being parsed at all?

That's the rustc parser doing the parsing, and it doesn't take rustfmt's config file into consideration.

cargo fmt is used to format entire packages. It determines some arg values (edition, the main entry point source file for the specified packages, etc.) which it passes to rustfmt for formatting, so if the specified package includes that snippet then the parser is going to hit it.

If you've got to keep that unparseable code, then you might have better luck running rustfmt directly against the individual specific files. I imagine you'll likely also need to use skip_children as well

[maplant]

Ah I'm sorry I had some build issues that were obscuring the parse error in my build; I genuinely thought the snippet I sent was valid. Oops!

[calebcartwright]

Ah I'm sorry I had some build issues that were obscuring the parse error in my build; I genuinely thought the snippet I sent was valid. Oops!

No worries! I found a couple things while looking through this that we should improve anyway, so it was a helpful question regardless!

[topecongiro]

Closing as if I understand correctly, the rustfmt error was due to the unparsable source code, which is expected behavior. Please feel free to reopen if there are any issues.