Add static selectors

[madsmtm]

My work on fixing upstream SSheldon/rust-objc#49.

A lot of work has gone into this, by many different people, see in particular the following:

• @pcwalton's investigation
• @mjbshaw's investigation, their Rust issue on statics and incremental compilation and their comment on Rust's unstable linkage feature
• @jrmuizel's Rust issue, similar to the above
• @clavin's discussion about their approach

This implementation is a combination of the following (git co-author attribution given where relevant):

• objrs' implementation
• @mystor's implementation
• @jrmuizel's implementation (fork of the above)
• @clavin's implementation
• @nvzqz's implementation (haven't yet looked at this)

I've cut down heavily on procedural macro usage, because I think the code is much more readable without (ideally we'll find a way to get rid of them entirely).

TODO:

• Set up ObjFW CI (ObjFW support #117) Postponed.
• More test cases in CI, including at least different linking tests, testing in generic functions, and perhaps also UI tests (Use trybuild for testing compilation failures #35) and LLVM/Assembly/... output
• Set up WinObjC CI Deferred
• Make this work on GNUStep Deferred
• Read LLVM, LLD and clang docs and sources
• Read objc4 sources so see how the loading happens
• Maybe make necessary changes to Rust to fix the linked issues with generics, incremental compilation and codegen units? Deferred, not really sure how it would be accomplished
• Should we verify asciiness and such of the selectors like objrs does? Deferred, documented as ill-supported for now.

See also:

• Linkme: safe cross-platform linker shenanigans
• ctor
• defmt's duplicate handling

[nvzqz]

You can re-export core in your crate and then access it from this macro as e.g. $crate::_core.

[madsmtm]

Yeah I know, I was just carrying over a TODO from previous authors. Thanks for the review though!

[madsmtm]

The defmt crate also hashes source code locations and puts them in export_name - so that approach is at least used elsewhere.

[madsmtm]

I think I'm gonna merge this as-is now, allowing users to enable and test this with the "unstable-static-sel" feature flag. It's still a bit rough on the edges, and involves a great deal of hacks and underspecified parts of the compiler, but I'm fairly certain it works.

The primary blocker for adopting this fully (in its most optimal form "unstable-static-sel-inlined", which is the whole point) is the Rust issue rust-lang/rust#53929 on how private statics aren't in the same codegen unit as the code that references them, which I don't really see a way forward on.

Also, we would probably have to have some parts of how the compiler works be more fully specified before we could really ensure that this is stable.