`#[linkage = "weak"] const fn` accepted without warning

[HaoboGu]

I'm trying to define a "weak" const in a library, which allows users to redefine their const. On stable Rust, there's no way to do it. On nightly, linkage feature seems the solution, but I found that it doesn't work as well. The following is the repro code:

// In library code:
#![feature(linkage)]

#[linkage = "weak"]
#[no_mangle]
const fn get_foo() -> i32 {
    0
}

pub const FOO: i32 = get_foo();

pub fn hello() {
    println!("hello: {}, {}", FOO, get_foo());
}

// In application code:
use linkage_weak_bug::hello;

#[no_mangle]
const fn get_foo() -> i32 {
    1
}

fn main() {
    // Output: hello: 0, 1
    // Expected: hello: 1, 1
    hello();
}

I uploaded a repo that could repro it: https://github.com/HaoboGu/linkage_weak_bug

[zopsicle]

Const items are always evaluated at compile time, which happens before linking, so this is expected. Perhaps const functions should not be allowed weak linkage, because it allows their compile-time and runtime behavior to differ.

[HaoboGu]

I think it's valuable to have "weak constants" in Rust, just disallowing weak linkage for const fns is not we want.

For example, in no_std env, it's very common to define a global channel with a fixed size:

// This is a simplified code
const CH_SIZE: usize = 4;
static CHANNEL: Channel<CH_SIZE> = Channel::new();

And, as a library author, we may want the CH_SIZE to be customizable by library users. It's impossible for Rust without using weak linkage now.

[bjorn3]

CHANNEL gets fully codegened when compiling the crate that contains it. To do this, it's full type needs to be known, which in turn requires CH_SIZE to be known. Note that the very fact if compilation succeeds or not and which functions get codegened can depend on the value of a const item or const function. As such weak linkage for const items and const functions can't work. And that is not even taking into account the fact that const items by definition don't have a symbol name unlike statics, but weak linkage matches on symbol name.

[workingjubilee]

Indeed, we may wish to investigate making this a compiler error.

But first, while an expert on the linking side of things has spoken, let us consult the experts on the CTFE side of things. cc @rust-lang/wg-const-eval do any of you wish to entertain the possibility of a const fn having its symbol name overwritten at runtime, and users like @HaoboGu consequently seriously misunderstanding the model?

[workingjubilee]

@HaoboGu The idea of "generic singletons" is an interesting idea, but it's absolutely not the way things work, and if it did work, it would have to be designed in such a way as to actually be evaluated without taking linkage into account.

[RalfJung]

No I don't think const fn intends to ever support terrible linker hacks like that. ;) If there's a use-case here, it should be solved with proper, type-safe Rust mechanisms, not at the linker level. What should even happen if 3 crates each overwrite get_foo (or CH_SIZE) with a different value? I don't see how we could have a sensible safe system here.

Even on regular fn this is rather questionable, considering things like inlining. What even is the semantics here? When you call get_foo it non-deterministically calls some function with that name? AFAIK currently we have a safety requirement on no_mangle that there must be only one function with that name, so technically your code has UB. We probably want to adjust this to support weak linkage since people want to use their terrible linker hacks, but we should do so carefully.