Implementation of import_name_type

[dpaoliello]

Fixes#96534 by implementing rust-lang/compiler-team#525

Symbols that are exported or imported from a binary on 32bit x86 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 #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.

This change adds a new MetaNameValueStr key to the #[link] attribute called import_name_type, and which accepts 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).

Design decisions (these match the MCP linked above):

• For GNU, decorated matches the PE Spec and MSVC rather than the default behavior of dlltool (i.e., there will be a leading _ for stdcall).
• If import_name_type is not present, we will keep our current behavior of matching the environment (MSVC vs GNU) default for decorating.
• Using import_name_type on architectures other than 32bit x86 will result in an error.
• Using import_name_type with link kinds other than "raw-dylib" will result in an error.

[rust-highfive]

r? @TaKO8Ki

(rust-highfive has picked a reviewer for you, use r? to override)

[dpaoliello]

r? @wesleywiser@michaelwoerister

[wesleywiser]

Overall, this looks pretty good, nice work!

[wesleywiser]

Awesome, thanks @dpaoliello!

@bors r+

[bors]

📌 Commit f847388 has been approved by wesleywiser

It is now in the queue for this repository.

[joshtriplett]

Thanks for working on this!

This looks good to me, with my lang team hat on.

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.

As a potential improvement for the future, I do think it might make sense to allow this attribute on a per-function basis as an override. That is not a blocker in any way, though.

[Dylan-DPC]

failed in rollup

@bors r-

@bors rollup=never

[dpaoliello]

@Dylan-DPC - I don't believe that failure is related to this change: the code that I added should only be enabled if someone actually uses the import_name_type property on the #[link] attribute, and that can only be used on x86 Windows.

[JohnTitor]

Yeah, @dpaoliello is right, @bors r=wesleywiser

[bors]

📌 Commit f847388 has been approved by wesleywiser

It is now in the queue for this repository.

[bors]

⌛ Testing commit f847388 with merge b771848c3bda7198ca2aa39d18b62bf36e0de759...

[bors]

💔 Test failed - checks-actions

[dpaoliello]

@wesleywiser build has been fixed, can we please retry?

[wesleywiser]

Sure!

@bors r+

[bors]

📌 Commit cc49c3e has been approved by wesleywiser

It is now in the queue for this repository.

[bors]

⌛ Testing commit cc49c3e with merge 9845f4c...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 9845f4c to master...

[rust-timer]

Finished benchmarking commit (9845f4c): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.5%	[2.1%, 2.9%]	3
Improvements ✅ (primary)	-2.3%	[-2.3%, -2.3%]	1
Improvements ✅ (secondary)	-4.4%	[-5.8%, -3.8%]	5
All ❌✅ (primary)	-2.3%	[-2.3%, -2.3%]	1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.2%	[-3.9%, -2.5%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.2%	[-3.9%, -2.5%]	2

Footnotes

1. the arithmetic mean of the percent change↩↩²↩³

2. number of relevant changes↩↩²↩³