Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.7k
GH-98686: Fix compiler warning forHAS_ARG#99106
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Python/ceval.c Outdated
| assert(opname!=NULL); | ||
| intoffset= (int)(next_instr-_PyCode_CODE(frame->f_code)); | ||
| if (HAS_ARG(_PyOpcode_Deopt[opcode])) { | ||
| if (HAVE_ARGUMENT <=_PyOpcode_Deopt[opcode]) { |
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.
HAVE_ARGUMENT isn't used directly anywhere else. I think casting and using HAS_ARG might be better.
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.
But we don't have to worry about things like pseudo-opcodes, right? This seems like exactly the sort of thingHAVE_ARGUMENT is meant for...
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.
Kind of. HAVE_ARGUMENT was there before we had pseudo-opcodes, and HAS_ARG just compared with it. Now we have pseudo-opcodes, and if I saw HAVE_ARGUMENT in the code now my first thought would be that this is a bug (a place where we didn't update for pseudo-opcodes). So the trick is to make this not look like a bug.
Uh oh!
There was an error while loading.Please reload this page.