Lint on `black_box`ing ZSTs

[tgross35]

If a function pointer is black boxed, the call is treated as opaque:

use core::hint::black_box;
use core::ops::Shl;

#[no_mangle]
pub fn coerce_to_fn() {
    let f: fn(u32, u32) -> u32 = u32::shl;
    let fbb = black_box(f);
    fbb(1, 2);
}

coerce_to_fn:
        push    rax
        lea     rax, [rip + <u32 as core::ops::bit::Shl>::shl::hf57c419aa60bbfeb]
        mov     qword ptr [rsp], rax
        mov     rax, rsp
        mov     edi, 1
        mov     esi, 2
        call    qword ptr [rsp]
        pop     rax
        ret

However, black boxing a ZST that implements Fn does nothing:

#[no_mangle]
pub fn with_zst() {
    let fbb = black_box(u32::shl);
    fbb(1, 2);
}

with_zst:
        ret

This difference is subtle and we should lint on it. Suggested by @beetrees.

For reference: https://rust.godbolt.org/z/nvoEcnxKh

[obeis]

@rustbot claim

[madhav-madhusoodanan]

Was tinkering with the optimization arguments to learn further about black_box when I came across this LLVM IR:
(rustc 1.85.0 -C opt-level=1)

For coerce_to_fn (before any LLVM optimization)

define void @coerce_to_fn() unnamed_addr {
  %1 = alloca [8 x i8], align 8
  %2 = alloca [8 x i8], align 8
  store ptr @"<u32 as core::ops::bit::Shl>::shl::hf57c419aa60bbfeb", ptr %2, align 8
  %3 = call noundef nonnull ptr @core::hint::black_box::hcf184167272ea754(ptr noundef nonnull @"<u32 as core::ops::bit::Shl>::shl::hf57c419aa60bbfeb")
  store ptr %3, ptr %1, align 8
  %4 = call noundef i32 %3(i32 noundef 1, i32 noundef 2)
  ret void
}

For with_zst (before any LLVM optimization)
(observe the call to the black_box function doesn't have any arguments being passed)

define void @with_zst() unnamed_addr {
  %1 = alloca [0 x i8], align 1
  call void @core::hint::black_box::h15436ec9ac8e7830()
  %2 = call noundef i32 @"<u32 as core::ops::bit::Shl<i32>>::shl::hacf3deea2942c26c"(i32 noundef 1, i32 noundef 2)
  ret void
}

Reference Godbolt example

Is there some issue with the way the LLVM IR is created for the black_box call in the with_zst example? I thought that specific line would be similar to the counterpart in the coerce_to_fn example (where it stores the result in %3 variable).

[tgross35]

I'm not sure if there is a better way to do this, but I'm also not an llvm expert. If you haven't figured something out, it might be worth asking on the LLVM channel #t-compiler/wg-llvm

[madhav-madhusoodanan]

I wasn't able to figure it out, I'm quite new to LLVM myself and I was just tinkering around in the Compiler Explorer example.

Thank you for suggesting me, I shall raise it up in the LLVM channel in that case.

[hanna-kruppe]

ZST values don’t correspond to anything at the LLVM IR level, this is intentional and not a bug. The proposed lint shouldn’t run on LLVM IR anyway (does rustc even have any infrastructure for such a lint?), but probably on MIR.