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
Ensures CBV semantics when eta-expanding function to eliminates optional arguments #1424
Conversation
…inate optional arguments.
@damiendoligez This surely has to go into 4.06, no? |
@mshinwell it's a really obscure bug that was never observed in the wild, not even by the original reporter. If you want to push it for 4.06, we need a review from a typechecker expert. The fix looks innocent enough to my novice eye but I know better than to trust my judgement where |
The change seems obviously sound, since the code for expansive expressions should always be valid for non-expansive ones. The previous use of the check was definitely incorrect since non-expansive gives no guarantees about purity. The only question is whether this might somehow affect performance for cases where the expression is both non-expansive and is pure. I think it's probably fine because an identifier being let bound won't make any difference and that will be by far the most common case. Also, code undergoing this transformation is probably quite rare anyway. So I approve of merging this, but maybe give Jacques an opportunity to comment as I think the original code was his. |
One might want to check whether this adversely affects the size of code for lablgtk, which is a big user of this feature. (This said, in most cases the argument is a method call, which is not nonexpansive anyway). |
@alainfrisch this PR will go to 4.06. Please write the |
|
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 change is certainly correct from a semantical point of view, and I agree with @lpw25 that in theory simplify
should remove the overhead. Still would be a good idea to check that there are no performance regressions.
@garrigue You mention that lablgtk is a heavy user of the feature. Do you have some specific benchmark you could try? |
The problem is not performance, just code size. So compiling the library before and after the fix, and check the size of the .cma and .a should be sufficient. |
I would like to request that we merge this fix without further delay. I don't really understand why benchmarking the code size of lablgtk is pertinent in the face of a bug involving miscompilation of side effects on an example as trivial as the one in MPR#7657. We need to check the performance / code size of the release as a whole in any case. |
…nal arguments (#1424) Fix MPR7657: ensure CBV semantics when eta-expanding function to eliminate optional arguments.
Merged and cherry-picked [4.06 a55915f]. We can check the lablgtk code size in parallel with other testing. |
Fixes MPR#7657.
(Waiting to know whether this goes to 4.06 or not to write the Changes entry.)