cfg arch-specific ABIs for unsupported_{,fn_ptr}_calling_conventions

[workingjubilee]

Addresses FCW lints to assure code will compile on Rust 1.89 and beyond, as these ABIs get translated to others if the cfg condition is not met.

[workingjubilee]

Currently includes #68 so this passes CI.

[workingjubilee]

There's a lot of possible decisions regarding how to mitigate the breakage from this, so I am happy to edit this appropriately. I just wrote out the boringly obvious one of "just take it on the chin" because most of the others seem like they'd want your input first.

[workingjubilee]

Specifically, all of these ABIs are silently translated to extern "C" if the cfg is not met. The type remains the same but the pointee is a different ABI in actual fact.

[Hpmason]

I'm not able to build docs locally at the moment but I believe this loses the feature attribute on the docs (since doc(cfg(...)) is the attribute that adds it in the generated docs

[workingjubilee]

Hm, is it? I'll revert that part of the change.

[Hpmason]

Is rust 1.89 changing how extern fns are treated when compiling for targets that don't support that specific extern? Or is it just changing warnings?

[workingjubilee]

@Hpmason Previously, using ABIs like extern "stdcall" on platforms that did not support them (for stdcall it was x86 or, oddly enough, Windows) was made a hard error. But the check was not done perfectly, so function pointers using these ABIs slipped through the linting and future compatibility warnings. So we have issued a separate lint on those for a bit now, and Rust 1.87 will warn even anyone who uses your library as a dependency about this concern.

I intend to propose that we switch this from a lint to a hard error for this case, because it makes the resulting behavior... does the code compile or not?... consistent for all usage of extern "{abi}" fn in all positions in the grammar, depending only on target support. This may land in 1.89, or 1.90, or even later.

Separately, in 1.89, we have already started linting on usage of ABIs that were allowed on Windows if they were a mismatching architecture. Those will remain functional even if my recommendation regarding switching to an error is followed. This lint will remain for a while longer as we will only start linting in 1.89, and it will be on a new axis we may get different feedback for.

So, I can fix up this PR to have either

• the set of cfgs for extern "{abi}"s that will still compile even if all the future compatibility warnings are made hard errors (current status of this PR)
• the set of cfgs for extern "{abi}"s that will still compile for 1.89 even if my recommendation is followed promptly, though they may trigger lints
• later this week, if T-lang manages to agree on what cfg_version syntax they want to ship, then I could even update this PR to use that, too, but that might be a bit optimistic

[workingjubilee]

Corrections to above statement in light of new information:

• Certain linting will be enhanced in 1.89, and that will not warn on this library's users but will warn you. It is unclear when, if ever, those lints will become hard errors.
• Certain ABIs will be hard-rejected in 1.90, and that will include use of extern "{abi}" fn(A) -> R on platforms which don't support "{abi}".

And to re-address this, specifically, and to perhaps better explain why we are making this change:

Is rust 1.89 changing how extern fns are treated when compiling for targets that don't support that specific extern? Or is it just changing warnings?

Previously to 1.90, we compute extern "{abi}" fn(A) -> R according to an arbitrary ABI chosen by the compiler. In some cases, we didn't even make such an arbitrary choice, and then it was possible the compiler would reach an internal compiler error. It was also possible for us to compute the ABI according to an impossible-to-codegen pattern and reach an error in LLVM, or to simply emit incorrect codegen that matched no ABI whatsoever.

Handling all of those edge-cases is not done in a principled way because people who initially proposed adding this ABI support to the compiler did not think about it enough to document what their intentions were. They were focused on addressing a use-case, instead of interacting with the "negative space" off the happy path.

[workingjubilee]

I do think my changes handle it in a principled way... if somewhat depressing if you were hoping to not interact with this complexity. Namely, we cut off its head. An invalid ABI will remain syntactically valid... it parses. But it will no longer proceed past AST expansion, so we conclude we must error on it before we even reach the typechecking phase. This is important because that particular step is the only point in the compiler which is guaranteed to see every instance of extern "{abi}".