Add explicit_extern_abis Feature and Enforce Explicit ABIs

[obeis]

The unstable explicit_extern_abis feature is introduced, requiring explicit ABIs in extern blocks. Hard errors will be enforced with this feature enabled in a future edition.

RFC rust-lang/rfcs#3722

Update #134986

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
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]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

[traviscross]

@rustbot labels +S-blocked
@rustbot author

We're still finalizing the timing and name of the next edition, and in any case, I think I'd like to see a separate PR for adding the various bits for the next edition that's separate from any edition item.

[workingjubilee]

I do not think we will accept the edition changes being folded into this PR, @obeis

[rustbot]

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

[bors]

☔ The latest upstream changes (presumably #139269) made this pull request unmergeable. Please resolve the merge conflicts.

[traviscross]

Let's please update that comment as suggested.

@rustbot author

After that, this looks OK to me as a lang and edition matter, and the impl looks OK to me, so r=me along with your own review.

r? compiler

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[obeis]

@rustbot ready
@bors r=@traviscross rollup

[bors]

@obeis: 🔑 Insufficient privileges: Not in reviewers

[bors]

@obeis: 🔑 Insufficient privileges: not in try users

[traviscross]

@obeis: That part of my note there was directed at the compiler reviewer I assigned.

[Nadrieril]

I would like this to be implemented as an allow-by-default lint, likely called implicit_extern_abis. Given how simple the lint is, we may not even need to put it behind a feature gate. If there's anything undecided then ok for the feature gate.

Having it as a lint makes it easy to deny on a later edition and makes the edition migration trivial. With the current implementation, I don't think we can easily do the "first make the crate muti-edition-valid, then update the edition" process, whereas with a lint one can just deny(edition_2027_migration_lints) (I forget the exact name).

[traviscross]

There already is a lint here (missing_abi), and it's already warn-by-default. It includes a machine-applicable suggestion even. What this PR is doing is making it a hard error (not a lint) in a future edition.

Playground link

[traviscross]

Making it a hard error is in accordance with RFC 3722.

In terms of process, once we add a new particular numbered edition (e.g. "Rust 2025"), the edition team will need to accept this change into that edition, and lang will need to make a decision to stabilize this in that edition.

Until then, this hard error must remain under a feature flag and can only be present in the future edition (introduced in #137606) which abides by a set of rules documented here and FCPed by the edition team.

[Nadrieril]

Oh, I see, I went a bit fast. All I want is a run-rustfix test in edition 2024 with deny(edition_future_compatibility) that checks that the migration is correctly applied. I think the way to make this happen is to add

    @future_incompatible = FutureIncompatibleInfo {
        reason: FutureIncompatibilityReason::EditionError(Edition::EditionFuture),
        reference: "issue #xxxx",
    };

to the lint declaration.

EDIT: oh, the lint is already warn-by-default so then there's no need for a new test. Still, this annotation would improve the error message.

[Nadrieril]

The hard error should have a suggestion too, in case someone changes the edition string by hand.

[traviscross]

I have mixed feelings about a suggestion in the new edition. One purpose of making this a hard error is that we don't want to suggest that "C" is the default any longer (and we may want to later consider making "Rust" the default). We do machine-applicable suggestions when we're really sure that's the right fix, but once we move away from this default, it's no longer actually clear that is what the user meant.

If we want to add some help text here telling the user that old editions inferred a default and that this is no longer true, and so the user needs to pick one explicitly, that'd of course be OK. If we want to go further and add a machine-applicable fix to this hard error, then I'd want a lang decision here to that effect.

[Nadrieril]

Help text sounds good, it solves the problem of "user updates edition without thinking, doesn't understand the new error".

[traviscross]

Oh, I see, I went a bit fast. All I want is a run-rustfix test in edition 2024 with deny(edition_future_compatibility) that checks that the migration is correctly applied. I think the way to make this happen is to add

    @future_incompatible = FutureIncompatibleInfo {
        reason: FutureIncompatibilityReason::EditionError(Edition::EditionFuture),
        reference: "issue #xxxx",
    };

to the lint declaration.

EDIT: oh, the lint is already warn-by-default so then there's no need for a new test. Still, this annotation would improve the error message.

This cannot be done. Please see my earlier review comment:

#135340 (comment)