Missed optimization: fn type calls returning never are not noreturn

[gnzlbg]

We currently do not annotate calls to function types returning Never as noreturn, but we probably should. This is similar to #64090 .

[varkor]

Here, it is suggested that we do:

rust/src/librustc_codegen_ssa/mir/block.rs

Lines 237 to 243 in 766b10a

	if self.fn_ty.ret.layout.abi.is_uninhabited() {
	// Functions with uninhabited return values are marked `noreturn`,
	// so we should make sure that we never actually do.
	bx.abort();
	bx.unreachable();
	return;
	}

Also see tests src/test/codegen/noreturn-uninhabited.rs and src/test/codegen/noreturnflag.rs.

[sanxiyn]

Closing. Currently noreturn attribute is applied, and it is tested that we do so.

[gnzlbg]

@sanxiyn where is it applied and could you point me to a test that checks this for fn type calls ?

I haven't been able to find any tests, and for this rust code:

extern "C" { static FOO: fn() -> !; }
pub unsafe fn foo() { FOO(); }

we emit:

@FOO = external global void ()*

define void @foo() unnamed_addr #0 {
start:
  %0 = load void ()*, void ()** @FOO, align 8, !nonnull !0
  call void %0()  ;; no noreturn here
  unreachable
}

like @varkor says and not

@FOO = external global void ()*

define void @foo() unnamed_addr #0 {
start:
  %0 = load void ()*, void ()** @FOO, align 8, !nonnull !0
  call void %0() #1
  unreachable
}
attributes #1 = { noreturn }

[sanxiyn]

Where it is applied can be easily found by grepping Attribute::NoReturn inside librustc_codegen_llvm.

[sanxiyn]

Guess: it seems noreturn is applied for Rust functions but not applied for extern functions?

[gnzlbg]

So how do you explain that the LLVM-IR generated by rustc that I just showed does not contain it ?

[gnzlbg]

@sanxiyn this issue is about function types, like fn() -> ! in let x: fn() -> ! = ...; x();.

[sanxiyn]

Oh.

[gnzlbg]

@varkor that comment says that functions returning uninhabited types are marked noreturn, but we can't mark function pointers noreturn (they don't support LLVM attributes). We can add attributes to the call site of the function pointer, e.g., as shown above, but since we are emitting an unreachable instruction right afterwards, then maybe it isn't necessary to do that ? If the function pointer call were to return, then unreachable would be reached, and the behavior would be undefined.