Use Default visibility for rustc-generated C symbol declarations

[chbaker0]

Previously, visibility for these symbols was determined by the default-hidden-visibility target option or the presence of -Zdefault-hidden-visibility. This leads to issue #123427, where use of the flag leads to undefined hidden symbols (i.e., references that can never be resolved to an exported symbol from another shared library) for functions often provided by a platform shared library, such as memcpy and memcmp from libc.so.

References to symbols provided by shared libraries must have default visibility. Hidden visibility is mostly useful for defined symbols.

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[chbaker0]

tagging @alexcrichton because their wasm additions introduced the original default-hidden-visibility field. I'm still unsure of all the nuances of how it should work for wasm.

[alexcrichton]

At the time the wasm target was added I vaguely recall that this was basically required to get the target working. For example it was just a quirk that was wasm-specific and wasn't intended to affect any other target. I don't recall the exact reason why it was necessary, but I vaguely recall it being required as otherwise all symbols were always exported from all wasm binaries. I just tried a local compilation with RUSTFLAGS=-Zdefault-hidden-visibility=no for wasm and it only exported the symbols I expected to be exported. Given that it should be ok to just flat out remove this option if it's causing problems.

[chbaker0]

We do actually want the command line flag for another use case: controlling symbol export when the final link step is not performed by rustc. Related: rust-lang/compiler-team#656 and #73295

If you build a staticlib or rlib without this option, then link it with C code into a shared object, all Rust symbols are visible in the SO. This is an issue if Rust is an internal implementation detail of the SO, and especially if you have more than one SO linked with Rust code.

[alexcrichton]

Ah ok makes sense! I can clarify then that at least for wasm-related stuff it's ok to disgregard this, I'll send a parallel PR to disable this option for wasm instead of enable it by default.

[lcnr]

r? compiler

[petrochenkov]

May check tcx.sess.target.dynamic_linking here as well if dynamic linking is the intended use case.
(Ideally all this would be configurable per function somehow.)

[petrochenkov]

This looks like a reasonable default for foreign functions.

The change have very little impact on unsuspecting users now because none of the built-in targets use default_hidden_visibility now (wasm was migrated off it), and -Zdefault-hidden-visibility is unstable and opt-in.

r=me after considering #123994 (comment).
@rustbot author