Implement per-symbol and per-crate versioned-API support

[graydon]

Currently we have very weak support for user-meaningful version numbers; a per-crate version number that is possibly mangled into the crate compilation name, but nothing else. Ideally we'd be using a symbol-versioning approach similar to the GNU-style @@vers stuff, outlined in the latter parts of https://mail.mozilla.org/pipermail/rust-dev/2010-December/000164.html and supporting multiple versioned-API exports from a single crate. Lots of work to do here.

[brson]

The situation is a lot better now and we can do some cool things with versioned crates (see the "crateresolve" tests). #2166 is one minor remaining issue.

[bstrie]

AFAIK Rust does mangle symbols according to the versioning info found in crate attributes. Can this be closed in favor of opening more specific bugs on whatever issues remain?

[pcwalton]

I don't believe this is backwards incompatible, renominating.

[graydon]

just a bug, removing milestone/nomination.

[catamorphism]

Cleared assignee. Nothing to add otherwise.

[mathstuf]

It would be nice to have something like:

#[symver="MYLIB_1_0"]
fn myfun(); // Accessible so that old binaries still work due to
            // an ABI change, but not through new compilations.
#[symver=default] // Defined at the crate level.
fn myfun(); // What is compiled against and put into the linker with
            // the default symbol version (defined at the crate level).
            // This version may have different semantics, but older
            // versions would be supportable without recompiles.

The #[symver] could be placed at any of the module, struct, impl, fn, or crate level and would be inherited. It probably doesn't make sense on traits though. It'd be nice to see a new language have support for much better ABI compatibility support out-of-the-box (out-of-the-crate?).

[emberian]

Nominating for closure. ABI versioning and stability itself is far off, and we already include crate version in the symbols.

[sinistersnare]

Does it being far off make this a non-issue? If we close this then it would be harder to find later, when we might want to look into this; whats the point of closing issues when they are not solved?

[emberian]

We have 1,584 open issues, and many of them aren't really actionable. If we want this, someone should write a detailed RFC. There's not really any valuable information in this issue.

[mathstuf]

And how many closed issues are there that would make it easy to find again? Could a tag be applied saying it should get an RFC? Or make a backlog tag (though github really needs a "not this tag" filter for that to work).