fix warnings in coreclr/jit/compiler.cpp for non-Windows targets #104805
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
dotnet-policy-service
bot
added
the
community-contribution
dicej
force-pushed
the
compiler-cpp-portability
branch
from
4ebf660
to
760f3db
Compare
dicej
force-pushed
the
compiler-cpp-portability
branch
from
760f3db
to
94ffdee
Compare
This change was extracted from dotnet/runtimelab#2614, which includes various fixes to enable building on non-Windows systems. We're in the process of upstreaming the parts of that PR which are not specific to NativeAOT-LLVM, and this is the latest such change. Note that I left a TODO comment in `DisplayNowayAssertMap` since I'm not sure how to print a `LPCWSTR` using `fprintf` on non-Windows systems, but it's clear that the existing code is not portable given the difference between `wchar_t` on Windows (where it's 16 bits) and other systems (where it's usually 32 bits). Signed-off-by: Joel Dice <joel.dice@fermyon.com>
dicej
force-pushed
the
compiler-cpp-portability
branch
from
94ffdee
to
250a96f
Compare
This borrows from dotnet/runtime#104805 Signed-off-by: Joel Dice <joel.dice@fermyon.com>
This borrows from dotnet/runtime#104805 Signed-off-by: Joel Dice <joel.dice@fermyon.com>
|
We will review it next week and merge as .NET 10. |
|
@EgorBo, please review the community PR. |
| @@ -1262,8 +1262,12 @@ void DisplayNowayAssertMap() | |||
| fout = _wfopen(strJitMeasureNowayAssertFile, W("a")); | |||
| if (fout == nullptr) | |||
| { | |||
| #if !defined(HOST_WINDOWS) | |||
| // TODO: how do we print a `const char16_t*` portably? | |||
There was a problem hiding this comment.
There are a lot more %ws in the jit codebase, why this one specifically is removed?
There was a problem hiding this comment.
e.g.
JITDUMP("Trying to unroll MemoryExtensions.Equals|SequenceEqual|StartsWith(op1, \"%ws\")...\n", str)There was a problem hiding this comment.
This is the only one the compiler complained about when building NativeAOT-LLVM on non-Windows systems. I haven't dug into why that is, but my guess is that either other cases of %ws aren't included in the NativeAOT-LLVM build, or else they're being used with expressions which are of type wchar_t* rather than char16_t*; the former is portable when used with %ws, but the latter is not.
There was a problem hiding this comment.
The reason this doesn't warn in other cases is because they are JITDUMPs, which compile down to logfs, which the compiler doesn't recognize as a printf-style function. I wonder if these other usages actually work properly on not-Windows.
Perhaps, @AaronRobinsonMSFT @jkoritzinsky know? |
We don't support that at present and it should be avoided. Convert to UTF-8 and log or display to prompt. I assume this is a non-product scenario, which means conversions should be performed or in the ideal case everything done in UTF-16 and then converted a single time. If this is a product scenario, we should discuss this. |
@dicej, please feel free to reach out to us if you need help on how to do this conversion. |
JulieLeeMSFT
added
the
needs-author-action
Sorry for the late reply. I guess I do need some guidance on how to do this in a way that would be acceptable for this PR. Is there an existing UTF-16-to-UTF-8 converter in the .NET codebase I could call? I see there's a I imagine that the user will only see sane output for non-ASCII characters if they're using a terminal and locale compatible with UTF-8, correct? I guess the "right" way to do this would be to check |
dotnet-policy-service
bot
removed
needs-author-action
|
Note that #109418 will subsume this PR, so at this point you might just consider waiting for that one. |
|
Closing this per @jakobbotsch's comment above. |
|
Actually, looking at this PR again, there are still a few non-UTF16 related changes here that #109418 did not subsume. Do you mind updating this PR to just resolve those? |
|
GitHub wouldn't let me re-open this after rebasing, so I opened a new one: #109830 |
This change was extracted from dotnet/runtimelab#2614, which includes various fixes to enable building on non-Windows systems. We're in the process of upstreaming the parts of that PR which are not specific to NativeAOT-LLVM, and this is the latest such change.
Note that I left a TODO comment in
DisplayNowayAssertMapsince I'm not sure how to print aLPCWSTRusingfprintfon non-Windows systems, but it's clear that the existing code is not portable given the difference betweenwchar_ton Windows (where it's 16 bits) and other systems (where it's usually 32 bits).