Add support for raw-dylib with stdcall, fastcall functions

[ricobbe]

Next stage of work for #58713: allow extern "stdcall" and extern "fastcall" with #[link(kind = "raw-dylib")].

I've deliberately omitted support for vectorcall, as that doesn't currently work, and I wanted to get this out for review. (I haven't really investigated the vectorcall failure much yet, but at first (very cursory) glance it appears that the problem is elsewhere.)

[rust-highfive]

r? @matthewjasper

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

[petrochenkov]

r? @petrochenkov

[ricobbe]

@rustbot label -S-waiting-on-author +S-waiting-on-review

[petrochenkov]

@ricobbe
Could you squash commits after addressing the remaining comments?

[ricobbe]

Could you squash commits after addressing the remaining comments?

Will do, sure. For my own understanding, what is preferred practice on this? Squash at the end before completing the PR, or squash as I go?

[petrochenkov]

@ricobbe

For my own understanding, what is preferred practice on this? Squash at the end before completing the PR, or squash as I go?

Both ways work for me.
The important part is to have a reasonable git history immediately before merging.

[ricobbe]

@rustbot label -S-waiting-on-author +S-waiting-on-review

[ricobbe]

@rustbot label -S-waiting-on-author +S-waiting-on-review

[petrochenkov]

@bors r+

[bors]

📌 Commit a867dd4 has been approved by petrochenkov

[bors]

⌛ Testing commit a867dd4 with merge 8d9d4c8...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 8d9d4c8 to master...

[joshtriplett]

This appears to have added a failing test:

8    = note: see issue #58713 <https://github.com/rust-lang/rust/issues/58713> for more information
9 
9 
10 error: multiple definitions of external function `f` from library `foo.dll` have different calling conventions
-   --> $DIR/multiple-definitions.rs:8:5
12    |
12    |
- LL |     fn f(x: i32);
-    |     ^^^^^^^^^^^^^
+ LL |         fn f(x: i32);
15 
16 error: aborting due to previous error; 1 warning emitted
17

[RalfJung]

This appears to have added a failing test:

How is that even possible...?

[fee1-dead]

This is weird, both #86922 and #86857 encountered this but they seem unrelated.

#87075 fails again.

[RalfJung]

Looks like we have different output on different targets?
But bors wouldn't have landed unless the stderr file is correct for all targets...

[RalfJung]

Is it possible that something depends on hash table ordering here (like the code that determines which of the "multiple definitions" the span is pointing at)?

[ricobbe]

I'm finding it a bit hard to follow the flurry of communications about this PR that happened over the weekend. What's the current status of this work--is the multiple-definitions test still failing in automation?

Is it possible that something depends on hash table ordering here (like the code that determines which of the "multiple definitions" the span is pointing at)?

An earlier version of this PR did indeed have this problem. I checked in a fix before the PR was merged, but it's possible that there's still some nondeterminism left.

EDIT: I think there is some nondeterminism left; sorry about that. Although I'm sorting the definitions before checking for multiples, I overlooked the fact that the comparison function I'm using doesn't guarantee a specific order in exactly the case that triggers the error. This should be a relatively simple fix.