Fix linking for symbols starting with ? on i686-pc-windows-msvc

[checkraisefold]

When using the export_name attribute to specifically export a symbol beginning with a question mark on the i686-pc-windows-msvc target, that symbol will fail to link and throw a linker error 100% of the time.
Issue writeup.

Closes #44282

I'm not sure if this is a proper solution, but LLVM does the same check which causes this issue, and is applied to all 32- and 64-bit Windows COFF objects (maybe the same patch should be applied for 64 bit windows as well then?). I am more unsure of whether this is the proper place for such a solution (and if the exact conditions of is_like_windows are proper for this usecase), or if the underscore should be stripped elsewhere, but it seems like the most correct place.

I'm also unsure if there are any backwards compatibility ramifications here. There shouldn't be, because binaries with exported symbols starting with ? for this target failed to link because of this issue anyway, but still.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @TaKO8Ki (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[checkraisefold]

Just tested this patch with rust-lld; the original issue exists with lld being used as well, not just MSVC's linker, and is fixed by this patch.

[jieyouxu]

cc @bjorn3, @petrochenkov and @ChrisDenton, in case anyone has any clues about this 😅

[jieyouxu]

Rerolling a reviewer. r? compiler

[alex-semenyuk]

@checkraisefold
From wg-triage. Could you please take a look question above

[rustbot]

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

[checkraisefold]

Apologies for the time it took to get to this - aside from being busy, for a relative Rust newbie (and contributing to the compiler, lol) especially the testing harness is very intimidating and it takes a while to iterate on my beautiful Ryzen 5 3600.

I was hoping to be able to fit this into a codegen or assembly test with some FileCheck annotations, but the technical difficulties of that are very annoying compared to a general run-make test - the compilation fails without this fix, which I tested, and it's a whole lot easier to implement.

[checkraisefold]

Seeing as the test no longer sucks-
@rustbot review

Additionally, run-make label can be removed

[jieyouxu]

r? compiler (assigned reviewer is on holiday)