9845f4c47e
Implementation of import_name_type Fixes #96534 by implementing https://github.com/rust-lang/compiler-team/issues/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](https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#import-name-type) 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 https://github.com/rust-lang/rust/issues/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. |
||
|---|---|---|
| .. | ||
| bootstrap | ||
| ci | ||
| doc | ||
| etc | ||
| librustdoc | ||
| llvm-project@e3be3f64ec | ||
| rustdoc-json-types | ||
| test | ||
| tools | ||
| README.md | ||
| stage0.json | ||
| version | ||
This directory contains the source code of the rust project, including:
- The test suite
- The bootstrapping build system
- Various submodules for tools, like rustdoc, rls, etc.
For more information on how various parts of the compiler work, see the rustc dev guide.