Code fails to link on macOS with incremental compilation

[jrmuizel]

The following code fails to link on macOS with incremental compilation. It works fine with incremental compilation turned off.

fn obj_alloc<T>(_p: T) -> *const [u8; 6] {
        struct Foo(*const [u8; 6]);
        unsafe impl Send for Foo {}
        unsafe impl Sync for Foo {}
        #[link_section="__TEXT,__objc_methname,cstring_literals"]
        static OBJC_METH_VAR_NAME_ : [u8; 6] = *b"alloc\0";

        #[link_section="__DATA,__objc_selrefs,literal_pointers,no_dead_strip"]
        static OBJC_SELECTOR_REFERENCES_: Foo = Foo(&OBJC_METH_VAR_NAME_);
        return OBJC_SELECTOR_REFERENCES_.0;
}

fn main() {
    let i: u32 = 0;
    obj_alloc(i);
}

The linker error is

  = note: Undefined symbols for architecture x86_64:
            "example::obj_alloc::OBJC_SELECTOR_REFERENCES_::ha196cc644aeae679", referenced from:
                example::obj_alloc::h54a034c209c8e4e3 in example-4a01b102e2898ce7.4jffkl93bkv60fxe.rcgu.o
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

The motivation for this weird code is getting native performance for objective-c message selectors. See SSheldon/rust-objc#49

[jrmuizel]

@michaelwoerister

[jrmuizel]

Here's the relevant portions of assembly.

Incremental:

        .section        __TEXT,__objc_methname,cstring_literals
__ZN7example9obj_alloc19OBJC_METH_VAR_NAME_17h2ea10c5dd1335938E:
        .asciz  "alloc"

        .private_extern __ZN7example9obj_alloc25OBJC_SELECTOR_REFERENCES_17ha196cc644aeae679E
        .section        __DATA,__objc_selrefs,literal_pointers,no_dead_strip
        .globl  __ZN7example9obj_alloc25OBJC_SELECTOR_REFERENCES_17ha196cc644aeae679E
        .p2align        3
__ZN7example9obj_alloc25OBJC_SELECTOR_REFERENCES_17ha196cc644aeae679E:
        .quad   __ZN7example9obj_alloc19OBJC_METH_VAR_NAME_17h2ea10c5dd1335938E

non-incremental

        .section        __TEXT,__objc_methname,cstring_literals
__ZN7example9obj_alloc19OBJC_METH_VAR_NAME_17h2ea10c5dd1335938E:
        .asciz  "alloc"

        .section        __DATA,__objc_selrefs,literal_pointers,no_dead_strip
        .p2align        3
__ZN7example9obj_alloc25OBJC_SELECTOR_REFERENCES_17ha196cc644aeae679E:
        .quad   __ZN7example9obj_alloc19OBJC_METH_VAR_NAME_17h2ea10c5dd1335938E

The notable difference is the addition of .private_extern

[jrmuizel]

And the LLVM ir.

Incremental:

@_ZN7example9obj_alloc19OBJC_METH_VAR_NAME_17h2ea10c5dd1335938E = internal constant <{ [6 x i8] }> <{ [6 x i8] c"alloc\00" }>, section "__TEXT,__objc_methname,cstring_literals", align 1, !dbg !0
@_ZN7example9obj_alloc25OBJC_SELECTOR_REFERENCES_17ha196cc644aeae679E = hidden constant <{ i8*, [0 x i8] }> <{ i8* getelementptr inbounds (<{ [6 x i8] }>, <{ [6 x i8] }>* @_ZN7example9obj_alloc19OBJC_METH_VAR_NAME_17h2ea10c5dd1335938E, i32 0, i32 0, i32 0), [0 x i8] zeroinitializer }>, section "__DATA,__objc_selrefs,literal_pointers,no_dead_strip", align 8, !dbg !9

non-incremental

@_ZN7example9obj_alloc19OBJC_METH_VAR_NAME_17h2ea10c5dd1335938E = internal constant <{ [6 x i8] }> <{ [6 x i8] c"alloc\00" }>, section "__TEXT,__objc_methname,cstring_literals", align 1, !dbg !11
@_ZN7example9obj_alloc25OBJC_SELECTOR_REFERENCES_17ha196cc644aeae679E = internal constant <{ i8*, [0 x i8] }> <{ i8* getelementptr inbounds (<{ [6 x i8] }>, <{ [6 x i8] }>* @_ZN7example9obj_alloc19OBJC_METH_VAR_NAME_17h2ea10c5dd1335938E, i32 0, i32 0, i32 0), [0 x i8] zeroinitializer }>, section "__DATA,__objc_selrefs,literal_pointers,no_dead_strip", align 8, !dbg !20

[jrmuizel]

Also, it's worth noting the link failure only happens with the constants inside generic functions.

[michaelwoerister]

Thanks for the bug report! Nominating for priority assignment.

[jrmuizel]

I think @pcwalton figured out what was going on here.

[pnkfelix]

triage: P-high

[pnkfelix]

hey @jrmuizel did you actually find anything interesting out from @pcwalton about this?

[pnkfelix]

assigning to @michaelwoerister under assumption that he is best suited to attack this issue

[jrmuizel]

Here's what he wrote: SSheldon/rust-objc#49 (comment). I don't know anything beyond that.

[pnkfelix]

visiting for triage.

I'm currently trying to understand whether this should remain at P-high or not; it sounds like servo is making do without this fixed, but there maybe efficiency issues (in our generated code) that could be addressed if we fixed this? not clear.

[pnkfelix]

visiting for triage again

@pcwalton do you have any input on whether this should remain at P-high?

(I figure if we have radio silence for another week, we should probably downgrade at the next compiler team meeting.)

[nikomatsakis]

Downgrading to P-medium for now. Please feel free to complain.

[nvzqz]

Has any progress been made here? I would like to emit selectors just like in ObjC/Swift in my library (issue: nvzqz/fruity#2).

[jrmuizel]

See also #53929