Reject unsupported, unstable ABIs during AST lowering

[workingjubilee]

Currently, we check whether ABIs have support on the target we are compiling for during HIR analysis. This unfortunately is a slightly "whack-a-mole" proposition, because there is no inherent relationship between ABI strings and their usages in the HIR¹. We can instead check for support in rustc_ast_lowering, where we first materialize ExternAbi from strings. This lets us always error on ABIs we wish to error on.

As a first step, we throw the switch for unstable ABIs. Despite being nightly features, we actually have emitted future compatibility warnings for all unsupported ABIs for some time:

• unsupported_calling_conventions became a hard error.
• unsupported_fn_ptr_calling_conventions is warn-in-deps since Rust 1.87, a stable Rust version.

With this we effectively make the latter lint a hard error on unstable ABIs. Stable ABIs still only receive warnings.

As a bonus, this addresses two ICEs that the compiler could reach. It prevents many more LLVM errors from being seen by programmers as well, as most unstable ABIs cannot have correct code generated for them by targets that do not support the ABI.

Fixes #132430
Fixes #138738

Footnotes

1. For example, we already missed some use-sites of ABI strings because FnSigs are not BareFnTys, requiring us to implement a new future-compat-warning to handle the function pointer case. ↩

[rustbot]

r? @Nadrieril

rustbot has assigned @Nadrieril.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

HIR ty lowering was modified

cc @fmease

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[workingjubilee]

@aDotInTheVoid Mm. I... am just gonna remove the extern "vectorcall" instances from these tests if that's alright? I don't see what useful coverage you're getting by testing for them if you already have e.g. extern "system" covered?

[rustbot]

These commits modify tests/rustdoc-json.
rustdoc-json is a public (but unstable) interface.

Please ensure that if you've changed the output:

• It's intentional.
• The FORMAT_VERSION in src/librustdoc-json-types is bumped if necessary.

cc @aDotInTheVoid, @obi1kenobi

[aDotInTheVoid]

I don't see what useful coverage you're getting by testing for them if you already have e.g. extern "system" covered?

It's checking that we produces the rustdoc_json_types::Abi::Other variant for ABI's that don't have a dedicated variant in rustdoc-json.

rust/src/librustdoc/json/conversions.rs

Lines 365 to 378 in 91fad92

	fn convert_abi(a: ExternAbi) -> Abi {
	match a {
	ExternAbi::Rust => Abi::Rust,
	ExternAbi::C { unwind } => Abi::C { unwind },
	ExternAbi::Cdecl { unwind } => Abi::Cdecl { unwind },
	ExternAbi::Stdcall { unwind } => Abi::Stdcall { unwind },
	ExternAbi::Fastcall { unwind } => Abi::Fastcall { unwind },
	ExternAbi::Aapcs { unwind } => Abi::Aapcs { unwind },
	ExternAbi::Win64 { unwind } => Abi::Win64 { unwind },
	ExternAbi::SysV64 { unwind } => Abi::SysV64 { unwind },
	ExternAbi::System { unwind } => Abi::System { unwind },
	_ => Abi::Other(a.to_string()),
	}
	}

rust/src/rustdoc-json-types/lib.rs

Lines 771 to 794 in 91fad92

	pub enum Abi {
	// We only have a concrete listing here for stable ABI's because there are so many
	// See rustc_ast_passes::feature_gate::PostExpansionVisitor::check_abi for the list
	/// The default ABI, but that can also be written explicitly with `extern "Rust"`.
	Rust,
	/// Can be specified as `extern "C"` or, as a shorthand, just `extern`.
	C { unwind: bool },
	/// Can be specified as `extern "cdecl"`.
	Cdecl { unwind: bool },
	/// Can be specified as `extern "stdcall"`.
	Stdcall { unwind: bool },
	/// Can be specified as `extern "fastcall"`.
	Fastcall { unwind: bool },
	/// Can be specified as `extern "aapcs"`.
	Aapcs { unwind: bool },
	/// Can be specified as `extern "win64"`.
	Win64 { unwind: bool },
	/// Can be specified as `extern "sysv64"`.
	SysV64 { unwind: bool },
	/// Can be specified as `extern "system"`.
	System { unwind: bool },
	/// Any other ABI, including unstable ones.
	Other(String),
	}

Could you instead change the tests to use some other unstable ABI here? But it's fine to only test this once (with both the -unwind and not cases), the current thing of testing every kind of abi everywhere an abi can appear is kind of excessive and provides very little value.

[workingjubilee]

@aDotInTheVoid Well. Most other unstable ABIs don't have "unwind" cases.

[workingjubilee]

I have pushed an alternative which does some rearrangement so that we don't have complications due to aarch64 hosts, still test an unstable ABI, and retain the vectorcall-unwind coverage when we do.