`#[inline]` prevents symbol from appearing in `staticlib` output

[jamesmunns]

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib.

Given this drastically simplified example:

/// lib.rs
#![no_std]

#[no_mangle]
pub extern "C" fn square_plus_one(input: usize) -> usize {
    square(input) + 1
}

#[no_mangle]
#[inline]
pub extern "C" fn square(input: usize) -> usize {
    input * input
}

use core::panic::PanicInfo;

/// This function is called on panic.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {
        // Prevent loop mis-optimization
        continue;
    }
}

# Cargo.toml
[package]
name = "inline-ffi"
version = "0.2.0"
edition = "2018"
description = ""
license = ""
documentation = ""
homepage = ""
repository = ""

[lib]
crate-type = ["staticlib"]

[profile.dev]
panic = "abort"

[profile.release]
panic = "abort"

The square_plus_one function makes it to the static library, but the square function does not:

nm -nSC ./target/release/libinline_ffi.a | rg square
0000000000000000 0000000000000009 T square_plus_one

If I remove the #[inline] attribute, we see both functions in the static lib:

nm -nSC ./target/release/libinline_ffi.a | rg square
0000000000000000 0000000000000008 T square
0000000000000000 0000000000000009 T square_plus_one

The relevant docs don't seem to hint that #[inline] can prevent #[no_mangle]/pub extern "C" items from surviving all the way to the final library, or that they shouldn't be used together.

I would expect any function marked pub extern "C" and/or #[no_mangle] should be present in the final artifact, regardless of #[inline] attributes.

I see this behavior on 1.43.1 stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this.

Thanks!

Edit: Simplified Cargo.toml profile settings, they are not needed to reproduce.

This issue has been assigned to @DoctorN via this comment.

[almindor]

Tried with 1.32.0 = same result

[cofibrant]

I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed

[Aaron1011]

This appears to have been done deliberately: #36280. Maybe it shouldn't apply to staticlibs.

[jamesmunns]

Expanding on @Aaron1011's note, I would also expect this not to apply to cdylibs as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).

[cofibrant]

I think I'm going to take this on

@rustbot claim