RFC: Allow symbol re-export in cdylib crate from linked staticlib

[aidanhs]

cc #2771, #3435, https://github.com/rust-lang/rust/issues/110624

Not sure if compiler team or lang team owns this.

Rendered

[vi]

Does this RFC propose to use pub fn foo to re-export the foo symbol even if it is actually not a function?

[aidanhs]

I've updated the RFC based on the comments above, including:

• clarifying that the RFC proposes to re-export both fn and static items if they have no_mangle applied on them in an extern block (in practice, on Linux if you re-export using the wrong type of item it'll work anyway...but such behavior is unspecified)
• adding some detail about when the warning was added in https://github.com/rust-lang/rust/pull/86376. cc @asquared31415, I want to make sure I've fairly represented the reasoning you had at the time and that you're convinced about the removal of the warning
• elaborating that there are multiple ways to explicitly specify a library is to be linked as static, both via the rustc command line as well as inline as an annotation on the extern block

The linked repository at https://github.com/aidanhs/rust-re-export-lib is now a much more extensive demonstration of the assorted combinations of pub, no_mangle and fn vs static. Take a look at the ext_rfc3556 extern block in https://github.com/aidanhs/rust-re-export-lib/blob/master/src/lib.rs, which describes what should happen in each case - on Linux, all the cases produce the correct binary output, but the warnings proposed by this RFC are missing.

[aidanhs]

@rustbot label +I-lang-nominated

Nominating this for the Lang Team to request that warning: `[no_mangle]` has no effect on a foreign function not be moved to a hard error before this RFC is reviewed.

(I'm not in a hurry for a review or discussion of the RFC itself - the feature works fine for me right now, I just don't want to regress!)

[rustbot]

Error: Label I-lang-nominated can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[asquared31415]

I want to make sure I've fairly represented the reasoning you had at the time and that you're convinced about the removal of the warning

I am fairly certain my reasoning at the time was along the lines of "no_mangle does too many things, and none of them are documented. It doesn't make sense to import and export the same symbol, because whatever you were exporting to could just import it from wherever you got the symbol." I think that this comment represents the best of my understanding at the time. I think there was too much focus on the fact that foreign items are not mangled (because they have to import by name) and a misunderstanding about exactly how no_mangle works, I think that everyone was operating under the assumptions stated in this comment by @Mark-Simulacrum:

Hm,I believe that no_mangle does not reexport extern static/fns (which are in some sense imports, as you say), and so no_mangle has no effect whatsoever on them, right?

It turns out that this isn't entirely true, specifically because something might import from a static lib and export as a dynamic lib, and the attribute does indeed make the symbol global. I think that it is reasonable to allow this use case and remove the warning stating that it is useless.

I still maintain the position of "no_mangle does too many things, its name doesn't describe half of its function, and docs don't exist". I would love to see work on that, but that is independent of this RFC.