Add import_name_type parameter to #[link]

[dpaoliello]

Proposal

(This is another attempt at #495)

Add a new parameter, import_name_type, to the #[link] attribute to be used with #[link(kind = "raw-dylib")] when importing functions on i686-pc-windows-* targets.

Symbols that are exported or imported from a binary on i686 Windows can be named in four separate ways, corresponding to the import name types from the PE-COFF spec. The exporting and importing binaries must use the same name encoding, otherwise mismatches can lead to link failures due to "missing symbols" or to 0xc0000139 (STATUS_ENTRYPOINT_NOT_FOUND) errors when the executable/library is loaded. For details, see the comments on the raw-dylib feature's rust-lang/rust#58713. To generate the correct import libraries for these DLLs, therefore, rustc must know the import name type for each extern function, and there is currently no way for users to provide this information.

I propose adding a new MetaNameValueStr key to the #[link] attribute. This key would be called import_name_type, and it would accept one of three values: decorated, noprefix, and undecorated.

A single DLL is likely to export all its functions using the same import type name, hence import_name_type is a parameter of #[link] rather than being its own attribute that is applied per-function. It is possible to have a single DLL that exports different functions using different import name types, but users could express such cases by providing multiple export blocks for the same DLL, each with a different import name type.

Note: there is a fourth import name type defined in the PE-COFF spec, IMPORT_ORDINAL. This case is already handled by the #[link_ordinal] attribute. While it could be merged into import_type_name, that would not make sense as #[link_ordinal] provides per-function information (namely the ordinal itself).

Open points of discussion:

• What does decorated mean for stdcall on GNU? dlltool doesn't include a leading _, should that be our behavior? Or should we add the _ to match MSVC? (I suggest: match MSVC - this gives us compatibility with the Win32 DLLs)
• What is the desired behavior if import_name_type is not present on an extern block? Should the compiler signal an error, use the system default, or fully decorate? (I suggest: system default - this matches the behavior when not using raw-dylib)
• Should the compiler signal an error or warning if import_name_type is provided in situations where it is not required, or should it silently ignore the extra parameter? These cases include the following:
  • Compiling for a target other than i686-pc-windows-* (I suggest: error - this has no effects except on i686-pc-windows-*, and matches the change to calling convention errors in Tracking issue for future-incompatibility lint unsupported_calling_conventions rust#87678).
  • Present in a #[link] attribute where kind is not "raw-dylib" (I suggest: error - this is a user error and will not do what they intended).
  • Present in a #[link] attribute on an extern block with a calling convention that doesn't decorate names (I suggest: error - this is a user error and will not do what they intended. NOTE: kind = "raw-dylib" already raises errors for unsupported calling conventions).

I have a prototype of this feature implemented via dpaoliello/rust@e86a32c

Mentors or Reviewers

Reviewer: @wesleywiser

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[petrochenkov]

@rustbot second

[wesleywiser]

@rustbot label -final-comment-period +major-change-accepted