-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replacing BOOL
with bool
#52585
Replacing BOOL
with bool
#52585
Conversation
Replaced all Windows' BOOL to bool in RyuJIT except for WIN API related cases. Fix dotnet#48317
Replaced `TRUE` with `true` and `FALSE` with `false` constants in RyuJIT except Windows-specific cases.
Formatting patch applied according to the instruction.
@@ -564,8 +564,7 @@ void Compiler::lvaInitRetBuffArg(InitVarDscInfo* varDscInfo, bool useFixedRetBuf | |||
info.compCompHnd->getMethodSig(info.compMethodHnd, &sigInfo); | |||
assert(JITtype2varType(sigInfo.retType) == info.compRetType); // Else shouldn't have a ret buff. | |||
|
|||
info.compRetBuffDefStack = | |||
(info.compCompHnd->isStructRequiringStackAllocRetBuf(sigInfo.retTypeClass)); | |||
info.compRetBuffDefStack = (info.compCompHnd->isStructRequiringStackAllocRetBuf(sigInfo.retTypeClass)); | |||
if (info.compRetBuffDefStack) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, my changes didn't affect this one (it was the suggested patch). CI didn't pass in the main branch, did it? 🦆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean? I do not think that the jit-format job deleted == TRUE);
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh, right, sorry, I'm blind XD. Yes, it's completely alright.
Okay, now it's ready for review. Are those failing CIs - my bad? |
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
@WhiteBlackGoose No, it was a break in the CI orchestrator. I've retriggered the build. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good (if only constexpr was used though for some of these that only returns booleans and safe checks). I know a lot of things in the stl that uses constexpr and noexcept
for things like those on these headers and things known within the functions callstacks to never throw.
As such I think a lot of the runtime that has bits that never throw should mark noexcept
and constexpr
if possible.
@JulieLeeMSFT could you review, please? I'm not sure if I have to ping someone, but no reaction for this and #51758 PR came from members, so I'm a bit confused 😕 |
@sandreenko PTAL. |
@WhiteBlackGoose sorry for the delay. Pinged @sandreenko for code review. |
I recommend you to tag @dotnet/jit-contrib in jit changes when they are ready for review so we get a notification about them. Otherwise, we scroll through all-new PRs from time to time but it would take longer until we notice it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks @WhiteBlackGoose!
@@ -564,8 +564,7 @@ void Compiler::lvaInitRetBuffArg(InitVarDscInfo* varDscInfo, bool useFixedRetBuf | |||
info.compCompHnd->getMethodSig(info.compMethodHnd, &sigInfo); | |||
assert(JITtype2varType(sigInfo.retType) == info.compRetType); // Else shouldn't have a ret buff. | |||
|
|||
info.compRetBuffDefStack = | |||
(info.compCompHnd->isStructRequiringStackAllocRetBuf(sigInfo.retTypeClass)); | |||
info.compRetBuffDefStack = (info.compCompHnd->isStructRequiringStackAllocRetBuf(sigInfo.retTypeClass)); | |||
if (info.compRetBuffDefStack) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean? I do not think that the jit-format job deleted == TRUE);
here.
Red CI seems to be reporting failures, the tests themselves passed.
|
503 is |
Checked on the failures. There's no failed tests. @sandreenko, if you feel like this is ready to merge please do so. @MattGal I've seen this issue with 503s starting to cause considerable pain, where we'll fail due to reporting even though all tests passed. Helix log searching in runfo is not very easy for this type of failures and Kusto ingestion happens from AzDO afaik so we can't use it. Is there any tracking issue for this? |
@hoyosjs this is the issue tracking that failure: https://github.com/dotnet/core-eng/issues/13026 and they are working on adding retries to the reporter: dotnet/arcade#7371 so maybe consider pinging there to raise their attention that we are being badly impacted? |
@hoyosjs nothing's changed about how often the 503s occur, they just now actually report failure starting 4/29. It's a long story, hit me up on Teams for a longer discussion. (Before 4/29, you were just able to merge failing tests if reporting to Azure DevOps failed). There is a simple and very quick fix that also causes failed work items to be logged in the test tab that is undesirable for this reason. dotnet/arcade#7371 is the FR issue that tracks introducing more retries to the script in the case of Azure Devops failure. |
Thanks @sandreenko for merging it. |
Replaced all Windows' BOOL to bool in RyuJIT except
for WIN API related cases.
Fix #48317