Closed lysnikolaou closed 4 years ago
If a helper returns NULL is always an error.
There are also the functions seq_{extract|delete}_starred_exprs
, which might return NULL and that shouldn't be an error. What are we doing with those?
What are we doing with those?
Can we factor out the parts that return NULL
for other reasons to the call site (if needed)? Maybe we need to enclose these functions in some helper that checks for error only on those or use another macro that also checks for PyErr_Occured()
.
@pablogsal Would something like 8cd74ed
work?
Also, could you quickly test out if there's an unexpected performance regression on your system?
Also, could you quickly test out if there's an unexpected performance regression on your system?
On it
On it
Nothing that I can detect. Microbenchmarks for individual rules show some micro-seconds of difference for the extra check but that is expected. I checked what happens when compiled with PGO with perf
(https://perf.wiki.kernel.org/index.php/Main_Page) and seems that the happy path branch is highly predictable so no problem.
On it
Nothing that I can detect. Microbenchmarks for individual rules show some micro-seconds of difference for the extra check but that is expected. I checked what happens when compiled with PGO with
perf
(https://perf.wiki.kernel.org/index.php/Main_Page) and seems that the happy path branch is highly predictable so no problem.
Nice.
Thanks a lot for the review!
Sorry, I realize it's a bit late, since this has landed already. But for readability, I kind of think that the macro could reference p
without it being passed in (since EXTRA
does the same), and since it's pretty common, it could be named just CHECK()
.
Sorry, I realize it's a bit late, since this has landed already. But for readability, I kind of think that the macro could reference
p
without it being passed in (sinceEXTRA
does the same), and since it's pretty common, it could be named justCHECK()
.
It's never too late. Opened #227.
Closes #224.