Implement #[link_ordinal(n)]

[ricobbe]

Allows the use of #[link_ordinal(n)] with #[link(kind = "raw-dylib")], allowing Rust to link against DLLs that export symbols by ordinal rather than by name. As long as the ordinal matches, the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL.

Part of #58713.

[rust-highfive]

r? @michaelwoerister

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

[ricobbe]

Question for reviewers: in attempting to clean up the error checking for link_ordinal in rustc_typeck/src/collect.rs beginning at about line 3156, I discovered that it's recording the ordinal, if present, to the function's CodegenFnAttrs struct. Should I be getting this information from there, rather than re-analyzing the attributes, in native_libs.rs? If so, how do I get a reference to the relevant CodegenFnAttrs object? Or should we drop this field from CodegenFnAttrs instead? As far as I can determine, it's only ever read by check_link_name_xor_ordinal in rustc_typeck/src/collect.rs.

(I refer to cleaning up the error checking because the messages rustc issues in certain circumstances are, at best, misleading: #[link_ordinal(3, 4)] is indeed invalid input, but complaining about an illegal argument format (unsuffixed integer value expected) in response is confusing.)

[est31]

@ricobbe I'm just giving my personal views here, am no reviewer in any official capacity, but I think that duplication should be avoided and ideally it should be re-used. I think it should be possible to obtain the attrs with something like self.tcx.codegen_fn_attrs(item.id.def_id), not entirely sure though.

Also, IMO the error message doesn't have to be perfect, but of course improvements are always nice.

[ricobbe]

@est31 Ok, I've pushed changes that use the info from CodegenFnAttrs. As another benefit, this also streamlines the error-detection code as well!

[michaelwoerister]

r? @joshtriplett

[ricobbe]

@joshtriplett do you have a sense of when you'll be able to take a look at this?

[joshtriplett]

LGTM from a purely language perspective. Deferring to compiler folks on the implementation strategy.

[ricobbe]

LGTM from a purely language perspective. Deferring to compiler folks on the implementation strategy.

@joshtriplett Thanks for the review! I'm happy for the compiler folks to take a look at it, though I will say that this PR is a straightforward extension of the basic import-by-name raw-dylib work from PR #84171.

[joshtriplett]

r? @michaelwoerister
for compiler team review of the implementation. No issues from a language semantics perspective.

[michaelwoerister]

I'll take a look tomorrow.

[michaelwoerister]

Looks great, @ricobbe! Thanks for adding so many tests.

@bors r+

[bors]

@michaelwoerister: 🔑 Insufficient privileges: Not in reviewers

[michaelwoerister]

@rust-lang/infra, any idea what that is about?

[michaelwoerister]

Let's give it another try: @bors r+

[bors]

📌 Commit 142f6c0 has been approved by michaelwoerister