RFC: #[no_mangle]

[pcwalton]

SDL wants you to define a function called SDL_main. We currently have no way to request that an extern function name not be mangled. Does an attribute for this make sense?

[brson]

Sounds good to me. I guess this would discard the module path, so you can define a #[no_mangle] function anywhere?

[alexrp]

(I'm not entirely up to date on the state of Rust's FFI, so take this comment with a grain of salt.)

I think mangling should be implied by the ABI of a function. Most calling conventions (on x86) carry particular mangling requirements - it just so happens that cdecl on most platforms means "no mangling". I think it will very rarely be useful to have a function be mangled in a particular way (or not at all) while having some arbitrary calling convention.

In D land, for example, marking a function extern (C) means that it will follow the calling convention and mangling rules of the target platform. There is no way to control mangling separately. I think that's a good thing since it encourages portable code.

To give a concrete example: If you created an SDL_main function, marked it as no_mangle, and tried to access it as extern void SDL_main(...); from C, it would work fine on Linux, but not on OS X since OS X's C ABI implicitly prefixes symbols with _.

[pcwalton]

@alexrp What about the case of a callback you want to be executed by C (so it must have the C ABI), but you don't care about its name, because you're passing the function by pointer? This is the case with every single callback we've defined up to now, so this isn't a "very rare" thing at all.

I'm concerned here about multiple crates defining a one-off callback with C ABI to hand to a C function and calling it, say, callback, and then having trouble at link time. Whereas if the functions named callback were mangled, everything would work fine.

[alexrp]

This is the case with every single callback we've defined up to now, so this isn't a "very rare" thing at all.

OK. I just went by my own experience and what I've seen in D land in particular (a lot of people seem to interface back and forth between C and D code). This may well be different in Rust land.

I'm concerned here about multiple crates defining a one-off callback with C ABI to hand to a C function and calling it, say, callback, and then having trouble at link time. Whereas if the functions named callback were mangled, everything would work fine.

That's a reasonable concern... maybe non-Rust-linkage symbols could have their name set to full_module_name_actual_symbol_name or something along those lines, e.g. a function foo in bar::baz would become bar_baz_foo (it would still be subject to ABI quirks such as a _ prefix and so on). Then you'd have to try very, very hard to get a collision. I think it even makes a lot of sense to prefix symbols with their module name.

With such an approach, you could then have a #[no_module_prefix] or so that makes the aforementioned foo function just foo if really needed (and still subject to ABI quirks - I still think having a raw "no mangling at all" attribute is a bad idea).

[eholk]

#[no_mangle] would be helpful in our Rust-on-GPU project, although there are probably better ways to solve our particular problem.

[brson]

Is adding the _ prefix on OS X something we have to do explicitly in rustc or does llvm do it? I am imagining that this is done at the LLVM level.

I would basically expect #[no_mangle] to follow the platform's C conventions, so I am partially persuaded by @alexrp's argument. But I also agree with concerns that not mangling so many symbols will interfere with symbol-level versioning.

We could alternately have a #[symbol_name = ""] attribute.

[graydon]

Doing it one-symbol-at-a-time risks the following:

#[symbol_name="foo"] extern fn foo() { ... }
#[symbol_name="bar"] extern fn bar() { ... }
#[symbol_name="baz"] extern fn baz() { ... }

which I can see getting a bit chatty for someone doing a library in rust that they intend to have a lot of C callers-of. Possibly combine with an attribute #[symbol_names="style"] that inherits through modules (so you can just write it once at a module level) and provides a few options: "simple", "qualified", "mangled"?

[pcwalton]

This is implemented now.