Require ABI for extern in 2021

[Mark-Simulacrum]

Proposal

Summary and problem statement

We do not currently require users to specify which ABI an extern corresponds to, in any context. This can be confusing (e.g., see rust-lang/rust#75030), and seems like an obvious case to fix. Requiring users to specify the ABI forces them to think through which ABI they want.

Motivation, use-cases, and solution sketches

The primary motivation is to ease reading code. Particularly with the introduction of "C-unwind" ABI, it seems increasingly true that knowing up front which ABI is associated with function pointers and function declarations is useful.

Prioritization

I think this best fits the targeted ergonomic wins -- similar to dyn, at least for me, seeing extern "C" is much clearer than just a bare extern. Though related to C Parity / embedded, it does not enable any new behavior that was absent previously.

Links and related work

C++ mandates only C and C++ ABIs, and requires an ABI to be specified on extern blocks, but not extern functions.

Initial people involved

No one beyond myself, at this point.

What happens now?

This issue is part of the experimental MCP process described in RFC 2936. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open MCPs in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[nikomatsakis]

Discussed in the lang-team team triage meeting today.

• This should be a fairly simple change to make.
• Some of us felt this was relatively poorly motivated, but @joshtriplett felt that implicit ABI was confusing to them when learning.
• For the moment, the choice of C still feels likely to be the predominant thing people want. However, it is true that "C-unwind" or other ABIs may make "C" feel less obvious.
• We're inclined to revisit this once "C-unwind" is implemented and stable.
• We think we should kick this to the @rust-lang/wg-ffi-unwind project group -- perhaps a first step would be adding an "allow by default" lint to discuss, and move it to warn by default later if it makes sense? (That move would require a lang team FCP.)

Tagging for close since this can be addressed in @rust-lang/wg-ffi-unwind for now. Will revisit next triage meeting.

[nikomatsakis]

Discussed in the meeting today. We're going to propose moving to an experimental implementation. Implement the lint and we can assess the impact via crater and make a decision whether to land with either allow-by-default or warn-by-default. From there, we could decide to make it an warning or error in a new edition. So closing as "approved" but without the requirement for a project group or RFC.

Also relevant, rustfmt already adds the ABI by default.

Note for future: There are also some discussion on Zulip on "related but orthogonal" issues such as name mangling and symbol export. We are not trying to solve those via this lint but we may want to address them at some other point.