-
Notifications
You must be signed in to change notification settings - Fork 584
eval_sv: add a G_USEHINTS flag #21421
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
Conversation
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.
Overall idea (and name) look fine.
Though I'm unsure about the idea of dropping the "feature/bits"
hh key in favour of this reconstruction mechanism.
@@ -12227,7 +12227,6 @@ Perl_ck_eval(pTHX_ OP *o) | |||
/* Store a copy of %^H that pp_entereval can pick up. */ | |||
HV *hh = hv_copy_hints_hv(GvHV(PL_hintgv)); | |||
OP *hhop; | |||
STOREFEATUREBITSHH(hh); |
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.
Hmm, took me a little while to work out why this bit, until I saw that we're now reconstructing the feature bits from the entire hinthash. Is that OK? In general the hh might contain a lot more keys (e.g. other bits of enabled syntax and options), so iterating the whole thing might take a little while, as compared just storing/fetching the UV as we used to.
I originally optimised populating cop_features for eval by storing the hints mask in "feature/bits" and then fetching that when re-populating the hints for eval. But that has turned out to be too fragile, so iterate over the possible feature keys and populate cop_features from that. I could perhaps have avoided this cost by ensuring "feature/bits" was set where else it was needed, but this code already iterates to build the hints hash, iterating again doesn't increase the scale of the work we're doing.
06129df
to
37f3e5a
Compare
I've changed this to iterate over the possible keys instead |
I'm confused though. Why is all the code necessary to reconstruct the features bits, when you removed the call to the |
Oh, now I read the commit message in the first of the two commits, that explains the situation more. In that case this is probably fine, though I think adding a |
37f3e5a
to
346e58f
Compare
Unfortunately the XS::APItest eval_sv() wrapper returns the result count rather than the result, so I can't check for 5, but I can check whether a result is returned. Which I've done. |
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
|
ext/XS-APItest/t/call.t is now producing noise on stderr. I'm not confident enough about what exactly is being tested to just add in a 'my $unused ='' etc.
|
Thanks fixed in e78b109 |
SV **fbsv = hv_fetchs((hh), "feature/bits", FALSE); \\ | ||
PL_compiling.cop_features = fbsv ? SvUV(*fbsv) : 0; \\ | ||
} STMT_END | ||
#define FETCHFEATUREBITSHH(hh) S_fetch_feature_bits_hh(aTHX_ (hh)) |
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.
This commit turned 1 hv_fetch()
, into 26 always failing hv_fetch()
calls, on a HV*
with only 1 key/1 HE* in it, with a key name of "CORE/prevailing_version".
SV **svp = hv_fetch(hh, fb->name, (I32)fb->namelen, 0); | ||
if (svp && SvTRUE(*svp)) | ||
PL_compiling.cop_features |= fb->mask; | ||
++fb; |
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.
This while loop has 26 hash key name entries to test/look for. All 26 hash keys, are never found in typical production perl code. The HV*
called hh
, has only 1 HE*/key in it total called "CORE/prevailing_version". Pretty bad O(n) problems here with this PR.
Fixes #21415