Support defaults for static EIIs

[AsakuraMizu]

Tracking issue: #125418

#154193 added EII support for statics, but left default implementations for "a followup PR". This PR implements it.

Maybe I should remove no-prefer-dynamic if #156577 is accepted.

[rustbot]

r? @mu001999

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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 17 candidates

[mu001999]

LGTM, but I’ll defer to @JonathanBrouwer in case I’ve missed anything.

r? JonathanBrouwer

View changes since this review

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[JonathanBrouwer]

I'm currently on holidays but would like to take a look, might take me a few days to get around to it

[JonathanBrouwer]

@bors r+ rollup
Looks good, thanks!
Wanted to implement this immediately after my PR that implemented static EIIs but forgot :3

View changes since this review

[rust-bors]

📌 Commit d7f16d7 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[JonathanBrouwer]

@bors r=JonathanBrouwer,mu001999

[rust-bors]

📌 Commit d7f16d7 has been approved by JonathanBrouwer,mu001999

It is now in the queue for this repository.

[JonathanBrouwer]

@bors r-
#156679 (comment)

[rust-bors]

This pull request was unapproved.

This PR was contained in a rollup (#156679), which was unapproved.

View changes since this unapproval

[AsakuraMizu]

After some investigation, I think this is hitting an LLVM issue: llvm/llvm-project#111321

For tests/ui/eii/static/auxiliary/decl_with_default.rs, rustc currently emits the following LLVM IR on aarch64-apple-darwin:

@_RNvNvCshLcOpHkWMCm_17decl_with_default1__5DECL1 =
  constant [8 x i8] c"\05\00\00\00\00\00\00\00", align 8

@_RNvCshLcOpHkWMCm_17decl_with_default5DECL1 =
  linkonce alias i64, ptr @_RNvNvCshLcOpHkWMCm_17decl_with_default1__5DECL1

The second symbol is the EII foreign item symbol. In the generated Mach-O object it becomes non-external:

0000000000000000 (__TEXT,__const) non-external __RNvCshLcOpHkWMCm_17decl_with_default5DECL1
0000000000000000 (__TEXT,__const) external     __RNvNvCshLcOpHkWMCm_17decl_with_default1__5DECL1

Then, when the aux crate is built as a dylib, ld64 fails because the linker’s initial-undefines list requires the EII symbol to be externally resolvable:

Undefined symbols for architecture arm64:
  "__RNvCshLcOpHkWMCm_17decl_with_default5DECL1", referenced from:
      <initial-undefines>

I also checked whether //@ no-prefer-dynamic would be enough. It is not: the aux crate can then be built as an rlib, but the EII alias symbol inside the object is still non-external, so the final executable link fails instead:

Undefined symbols for architecture arm64:
  "__RNv...decl_with_default...DECL1", referenced from:
      default_cross_crate::main

What should I do here?

1. Temporarily skip the new cross-crate static-default tests on Apple targets and leave a FIXME.
2. Refactor to avoid weak aliases for static EII default impls: emit the default value directly under the foreign item symbol with weak/linkonce linkage.
3. Fix the LLVM issue.