RFC: remove linkage attributes

[catamorphism]

#[link(name="foo", version="3.1415927", uuid=xxxxxxxx)] is an artifact of the pre-rustpkg days. rustpkg infers the link name from the package ID, and the version from version control if it's available. @graydon and I suggest that we warn if linkage attributes are present, and eventually start ignoring them as well as warning.

[brson]

where does rustc get the name and version? how will this impact non-rustpkg crates?

[graydon]

I'm ok keeping support for the name and vers attributes in the compiler for non-rustpkg crates. Rustpkg should warn on them though, as they override (possibly break) those provided by it, and we should remove all uses as we convert to rustpkg. Uuid and url should go entirely, though I don't think we even use them for anything presently.

[emberian]

@catamorphism I'm going to need some guidance on emberian/rustdoc_ng#15 if this goes through.

[catamorphism]

@brson I'm ok with @graydon's suggestion to keep support in rustc but have rustpkg warn about them.

[metajack]

I think that's fine, although I think version is the exception here. Maybe only warn if it's inferrable and set?

[catamorphism]

We decided to allow name and version in both non-rustpkg and rustpkg crates, but rustpkg will check that the name is the same as the inferred name, and the version is the same as the inferred version, and error out if either is inconsistent. We will eliminate any code that recognizes "uuid" and "url" specially, but we will still allow arbitrary additional attributes (these get used to compute the hash from the link attributes).

[Kimundi]

So if you leave those two off in a library, will rustc emit the current warning about assuming name=bin name and version=0.1, but if compiled with rustpkg it won't because it inferred?

And you can just add additional attributes to allow distinguishing versions of the library beyond the default fields?

[catamorphism]

@Kimundi The first is a good question. I'm inclined not to change the current behavior, so then the answer would be yes.

And yes, you'll still be able to add additional attributes to allow distinguishing versions of the library.

[catamorphism]

@metajack points out that our proposed solution has a problem: if you compile the same package with both rustc and rustpkg, you have to remove the name attribute, but in that case rustc will always treat the link name as "lib".

[catamorphism]

As an interim step, rustpkg should at least always inject a package ID; currently, it doesn't do that if you supply your own name and vers, causing confusion.