MinGW: enable dllexport/dllimport

[mati865]

Fixes (only when using LLD) #50176
Fixes #72319

This makes windows-gnu on pair with windows-msvc when it comes to symbol exporting.
For MinGW it means both good things like correctly working dllimport/dllexport, ability to link with LLD and bad things like #27438.

Not sure but maybe this should land behind unstable compiler option (-Z) or environment variable?

[rust-highfive]

r? @matthewjasper

(rust_highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

r? @petrochenkov

cc @retep998, do you know anything about the changes in src/librustc_codegen_llvm/context.rs by chance?
(I've seen the other parts of this PR in #70852, but didn't investigate this one yet.)

[retep998]

@petrochenkov This table covers dllimport linking success in the MSVC case: #27438 (comment)

For MinGW, several more of those entries become success instead of error (because it tries really hard to support minimally ported C code from non-windows which never put any thought into dllimport/dllexport), however the case of plain static with dynamic library is still always an error because direct access to a static cannot be redirected with a thunk the way functions can.

We should absolutely emit the appropriate dllimport/dllexport attributes on all Windows targets including MinGW as the resulting codegen is still better when done correctly.

[petrochenkov]

@mati865
Could you add a test for #72319?
Tests using nm are usually put into the run-make directory.

[mati865]

#72319 happens only when linking specific libs like llvm-libunwind. I have no idea what makes it so "special" but the test would probably require shipping that library...

[petrochenkov]

Ok, I think this is similar to #70937 in the sense that it should be the right thing to do, it affects only windows-gnu, but there may be compatibility issues.

So, same comments from #70937 (comment) apply, and we can choose the same process of dealing with the change - land it and see whether it causes any complaints in practice.

[petrochenkov]

#72319 happens only when linking specific libs like llvm-libunwind

Ok, shipping libunwind for a test is overkill.
(Although it would be great to figure out what happens exactly.)

[petrochenkov]

@bors r+

[bors]

📌 Commit c9bd8320cd9a63580c2f2624636585d858b5c07f has been approved by petrochenkov

[mati865]

@bors r-

Sorry but there is one missing change here. I'd have committed it already but had to fix undefined reference to __ms_vsnprintf first and I'm waiting on all tests passed.

[petrochenkov]

I don't have anything new to say compared to #72049 (comment), unfortunately.

r=me after squashing commits if this doesn't break tier 1 targets.

[petrochenkov]

Needs a tidy fix.

[petrochenkov]

@bors delegate+

[bors]

✌️ @mati865 can now approve this pull request

[mati865]

Apparently I forgot to hit submit button after the rebase.
I've reworded my in-code comments hoping they are clearer now. I'll spellcheck them and fix tidy tomorrow.

[mati865]

I don't expect any breakage on the affected targets (only windows-gnu) but we should start testing ASAP and if need we can revert it for beta to give more time.

@bors r=petrochenkov

[bors]

📌 Commit 87abd65 has been approved by petrochenkov

[bors]

⌛ Testing commit 87abd65 with merge 584e83d...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: petrochenkov
Pushing 584e83d to master...