-
Notifications
You must be signed in to change notification settings - Fork 124
[HIP] Refactor error handling in enqueue.cpp #1190
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
[HIP] Refactor error handling in enqueue.cpp #1190
Conversation
f614c49
to
c451bf2
Compare
c451bf2
to
f837719
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #1190 +/- ##
=======================================
Coverage 15.46% 15.46%
=======================================
Files 238 238
Lines 33883 33883
Branches 3747 3747
=======================================
Hits 5239 5239
Misses 28593 28593
Partials 51 51 ☔ View full report in Codecov by Sentry. |
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
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.
Really like this, needless accumulation of error codes in Result
-like variables, instead of straight out returns, and not using UR_CHECK_ERROR
are one of my top pet hates. Thank you!
f837719
to
0011dd3
Compare
@npmiller please take a look when you can |
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, sorry about the late review!
a2c1f16
to
f989b69
Compare
f989b69
to
5ebd333
Compare
source/adapters/hip/enqueue.cpp
Outdated
// but currently unmapped advice arguments as not supported by this | ||
// platform. Therefore, warn the user instead of throwing and aborting | ||
// the runtime. | ||
if (Result == UR_RESULT_ERROR_INVALID_ENUMERATION) { |
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.
I may be missing something here but is this if (Result == UR_RESULT_ERROR_INVALID_ENUMERATION)
meant to be checked again inside the above if (Result == UR_RESULT_ERROR_INVALID_ENUMERATION)
? It is already true in this case. Was it meant to be wrapped in if (Result != UR_RESULT_SUCCESS)
-> check if equals invalid then msg and return else throw
?
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.
I think I messed up the rebase here, now it just falls through to UR_CHECK_ERROR(Result)
if we aren't doing the adapter specific thing
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.
Yeah that makes sense to me now. Thanks, I actually thuoght it must've been a dodgy rebase by the looks of 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.
I know I am super late to the party here. Generally looks good. Thank you for cleaning that up!
Just a little comment I was confused about.
Mostly by taking the existing try/catch/UR_CHECK_ERROR based approach and making sure it's used consistently so as not to drop any errors.
d070776
to
96468e2
Compare
LLVM testing intel/llvm#12481