refactor ABI formatting

[fee1-dead]

whenever we see an extern "Rust" on a function, we don't strip it from the function (which fixes #5701)

[calebcartwright]

I'd be glad to move ahead with the first aspect of the change (although I'd still like to see whether #2908 is already fixed, or would be fixed by this), but we cannot make the second change.

Rustfmt's default behavior does not remove the "C" ABI and would add one in the event the input code was missing it. That's the required default as per the Style Guide (refs https://doc.rust-lang.org/nightly/style-guide/items.html#extern-items) with the discussion and reasoning being captured in rust-lang/style-team#52.

Setting the force_explicit_abi option to the non-default value false is intentionally doing the opposite, as noted in the config option docs:

https://github.com/rust-lang/rustfmt/blob/master/Configurations.md#force_explicit_abi

Note: Non-"C" ABIs are always printed. If false then "C" is removed.

Since force_explicit_abi is a stable option, we cannot change this behavior, at least not outside a style edition boundary change. We could potentially evolve this option to be an enum instead of a boolean to offer the equivalent of AlwaysAdd/AlwaysRemove/PreserveExistingButDoNotAddNew as part of the 2024 style edition, but we can't change this now and I wouldn't want to change the boolean behavior to the third variant

[fee1-dead]

Oh well. I just think that it is unfortunate that rustfmt has to support this and that the option is already stable. I think stripping the extern "C" isn't something that rustfmt should be able to do (to me i don't think rustfmt should add or remove tokens, but I guess people have their opinions)

[calebcartwright]

to me i don't think rustfmt should add or remove tokens, but I guess people have their opinions

fwiw I understand this thinking, and there are plenty of cases where we decline to add functionality to rustfmt because the ask seems like a better fit as a lint with something like rustfix providing the automated remediation capability.

However, some key decisions were made long, long ago to have a defacto standard Rust Style with rustfmt being provided to take any arbitrary input and being able to manipulate that input to conform with that standard. That inherently establishes scenarios where rustfmt has to add or remove tokens (not to mention there are some cases, including recent ones, where it's necessary to add/remove parens or braces in order to be able to format code without invalidating it or failing to uphold semantics).

There's tradeoffs to the pretty-printing model with potential token adjustments of course, and the more whitespace-adjustment oriented formatters that don't manipulate tokens have their respective pros & cons too

[fee1-dead]

i've restored the force_explicit_abi = false behavior.

[calebcartwright]

To recap for posterity, the changes have been good to go for a while, but we had some external discussion in various places in Zulip to first confirm there wasn't any subtlety in the Style Guide that would be impacted/contradicted by this small (non-breaking) update in rustfmt behavior.

Essentially the interpretation of the respective Style Guide prescription is that if the user has explicitly added the extern keyword themselves then the "Always specify the ABI" rule should apply, including for the "Rust" abi.

Note that this interpretation does not extend to the case of the implicit/default abi (i.e. it does not mean fn foo() must be modified to extern "Rust" fn foo()), which functionally leaves the decision of whether to have the explicit extern "Rust" to the developer.

If there's any future desire to have rustfmt remove an explicit Rust ABI, as it historically did prior to this change, then we can consider updating the rustfmt config surface to support that scenario

[calebcartwright]

@fee1-dead ping me whenever you get a chance to resolve the conflicts and I'll get it merged 👍

[fee1-dead]

@calebcartwright: rebased

[ytmimi]

@fee1-dead thanks for your help on this! @calebcartwright I could merge this one, so I went ahead and did so.