Tracking Issue for bare_link_kind

[ChrisDenton]

This is spun off from RFC 1717 (rust-lang/rfcs#1717) which is already implemented for #[link(name = "...", kind = "dylib")]
The feature gate for the issue is #![feature(bare_link_kind)].

Summary

rust-lang/rfcs#1717 implemented dllimport semantics for Windows externs (see the RFC for details). That is, it tells codegen to mark an item as being imported from a DLL:

// kind is "dylib" so dllimport applied to BAR and baz
#[link(name="foo", kind="dylib")]
extern {
    static BAR: u32;
    fn baz();
}

This tracking issue is for applying dllimport without knowing the lib name. E.g.:

// the lib is supplied separately
// via a build script, the command line, an external build system or even just a separate extern block.
#[link(kind = "dylib")]
extern {
    static BAR: u32;
    fn baz();
}

Only "dylib" and "static" kinds are allowed to be used without supplying a name.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implementation (Allow #[link(kind = "dylib")] without a name #131966)
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

Implementation history

• Implement RFC 1717 #37973

[ChrisDenton]

I'd emphasise that the use of dllimport was already decided in the RFC. This is just for applying them without giving a lib name. Given the limited scope of this I was persuaded that it doesn't need a new RFC but it still needs some form of @rust-lang/lang approval.