rustc: Support various flavors of linkages

[alexcrichton]

It is often convenient to have forms of weak linkage or other various types of
linkage. Sadly, just using these flavors of linkage are not compatible with
Rust's typesystem and how it considers some pointers to be non-null.

As a compromise, this commit adds support for weak linkage to external symbols,
but it requires that this is only placed on extern statics of type *T.
Codegen-wise, we get translations like:

    // rust code
    extern {
        #[linkage = "extern_weak"]
        static foo: *i32;
    }

    // generated IR
    @foo = extern_weak global i32
    @_some_internal_symbol = internal global *i32 @foo

All references to the rust value of foo then reference _some_internal_symbol
instead of the symbol _foo itself. This allows us to guarantee that the
address of foo will never be null while the value may sometimes be null.

An example was implemented in std::rt::thread to determine if
__pthread_get_minstack() is available at runtime, and a test is checked in to
use it for a static value as well. Function pointers a little odd because you
still need to transmute the pointer value to a function pointer, but it's
thankfully better than not having this capability at all.

Thanks to @bnoordhuis for the original patch, most of this work is still his!

[alexcrichton]

cc #11978 (original implementation)

[bharrisau]

I get that it is a pointer type/length anyway, but why the *u8 instead of *F?

[huonw]

fn() is a function pointer already, so *F would be a pointer to a function pointer. (And this is part of the reason that this change was necessary: function pointers are a slightly peculiar mix of pointer and value.)

[alexcrichton]

@huonw's answer is spot on.

[bharrisau]

So the FFI tutorial should recommend that *u8 is used in this case? (I was thinking about writing up some docs for this when it lands and just want to know what the recommended practice is)

[alexcrichton]

This is a gated feature because it is not supported on all platforms and I'm not sure that we'll want to stick with this interface forever. I wouldn't be opposed to docs, of course, though.

Any pointer would suffice here, it's essentially a "pointer to instructions" which varies per platform. I suppose a more proper type would be something like *() so you can't read it?

[bharrisau]

*() feels more special than rand(*u8, *i8, *u16, *i16, etc). ;)

[huonw]

What about static hopefully_this_symbol_doesnt_exist: *int; and checking that it's null? (And that compilation succeeds.)

[huonw]

"or *mut T"?

[bharrisau]

Is it worth adding a WeakFn trait to std::ptr. Just copy the RawPtr but change the to_option to give an Option<T> instead of Option<&T>. impl it for *u8 (or *Any).

[alexcrichton]

Is it worth adding a WeakFn trait to std::ptr

Due to this being a gated feature, I don't think that's necessary at this time.

[huonw]

Neat macro, maybe it should take an argument that's the monetary value of the asset too?

(I think you're missing an r.)

[huonw]

*mut pointing to a non-mut static? Feels like bad practice, even for a test.

(Also, it's a little unfortunate that this only works on Linux :( )

[alexcrichton]

Sadly weak linkage doesn't work so great elsewhere. I think it may work on android (linux based), but it definitely doesn't work on windows and OSX needs extra linker flags to get it to work. I can swap the mut pointers around though.

[huonw]

It might be better to have #[linkage(extern_weak)] etc, it feels less freeform that way? (And, anyway, we're going off the #[... = "..."] syntax.)

[alexcrichton]

I was a little curious about that when writing this, but I'm not entirely sure if it's going away at this point. move #[..]; to #![..] then I think we'll keep name = "value" at the top-level for now.

Semantically, "name equals value" seems like the right thing for this rather than "name with a value sub-attribute". Of course this is fairly easy to change, and I don't mind too much.

[bharrisau]

Bors is close to getting bored. Is this waiting on anything?

[alexcrichton]

ping r?

[flaper87]

I'd prefer to have linkage[123].rs squashed in a single compile-fail test. Also, it would be nice to have a small description of what the test is doing.

Could the test file be renamed to linkage-weak ?

[alexcrichton]

linkage1 must be standalone because it's testing the feature gate, and the other two could be combined, but there'll always be at least 2.

These are testing the linkage attribute, not just weak linkage, so linkage-weak is a bit deceptive.

[flaper87]

+1 for not renaming, it'd be nice to have a comment and perhaps merge the other 2, though. I'd expect other linkage tests to be added there.

[alexcrichton]

Ah, I remember now, an error is a span_fatal rather than a span_err, so that's why they're in separate files.

[flaper87]

oh ok, then nevermind, 😄 (mind adding a comment?)

[flaper87]

nice 👍

[flaper87]

I just have a couple of nitpicky comments.

[alexcrichton]

r=brson

[bors]

saw approval from brson
at alexcrichton@699b33d