Machineary behind an unreachable `panic!` ends-up in final optimized binary about rust HOT 6 CLOSED

I only see a single call to panic_fmt in the linked godbolt code. This is inside the _unreachable() function, which is never called, but still codegened as it is referenced from a public inlineable function (BytesVector::push) and thus could be referenced if optimizations are disabled for another crate which calls BytesVector::push. If you were to compile it as executable instead of as library (godbolt always compiles as library), then it would be removed after optimizations. Now it merely gets removed during linking due to --gc-sections.

from rust.

Probably a LLVM thing? cc @nikic

from rust.

Doesn't reproduce on play.rust-lang.org (release, 1.78.0-nightly) with main function added.
https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=41cee2ecbe0b343ff62b46424ee0e0af

alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle:
# ...
.LBB6_8:
	callq	*alloc::raw_vec::capacity_overflow@GOTPCREL(%rip)
.LBB6_6:
	movq	24(%rsp), %rsi
	callq	*alloc::alloc::handle_alloc_error@GOTPCREL(%rip)
                                        # -- End function

playground::foo: # @playground::foo
# %bb.0:
	pushq	%rbx
	movq	(%rdi), %rax
	movq	16(%rdi), %rsi
	subq	%rsi, %rax
	cmpq	$1, %rax
	jbe	.LBB7_1

.LBB7_2:
	movq	8(%rdi), %rax
	movw	$256, (%rax,%rsi)               # imm = 0x100
	addq	$2, %rsi
	movq	%rsi, 16(%rdi)
	popq	%rbx
	retq

.LBB7_1:
	movq	%rdi, %rbx
	callq	alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle
	movq	%rbx, %rdi
	movq	16(%rbx), %rsi
	jmp	.LBB7_2
                                        # -- End function

playground::main: # @playground::main
# ...

from rust.

@rustbot +requires-nightly

from rust.

but still codegened as it is referenced from a public inlineable function

Oh... That makes sense... I guess a local literal panic! in push won't be generated because it is in the standard library?!

Still not sure why #[inline] const fn _unreachable() -> ! { ... } isn't also generated but it probably isn't a problem with LLVM!?

from rust.

OK, thanks @bjorn3 and @ProgramCrafter

from rust.