SI-8898 javap -fun under new style lambdas#4069
Conversation
|
PLS REBUILD/pr-scala@a153c05f8a3ea6771d5e0b9afaed4f7e1df00403 |
|
(kitty-note-to-self: ignore 59920510) |
|
That's a real error; I broke the stripped output. I'll push the fix shortly. @lrytz Actually, just remembered the other issue is that the non-uniformity of the lambda class names means extra work to distinguish class and module closures. That's the other fix to push. |
2d6ec85 to
ecffc95
Compare
|
Dear kitteh, I guess I am a dog person. |
|
PLS REBUILD ALL Pretty please. On the weekend, like in the old days, when you'd go to the computer room to submit jobs off-hours. |
|
(kitty-note-to-self: ignore 61382067) |
|
LGTM - this will require change (again) once closures are emitted in Java-8 style (invokedynamic and LambdaMetaFactory), but it should become easier to find the delambdafy:method-method (no longer need to grep for the |
To support both -Ydelambdafy strategies, look for both inline (anonfun) and method (lambda) closure classes. For method (lambda) style, use the anonfun method that is invoked by the accessor. Also, the output of javap must be captured eagerly for filtering for the current target method. If the user asks for a module, e.g., `Foo$`, don't yield results for companion class, but for `Foo`, do yield companion module results. Just because.
|
Pushed the minor edits. Hope it didn't break. |
SI-8898 javap -fun under new style lambdas
|
@lrytz it's an inherently brittle feature, at least as impl'd. Wasn't sure it was worth it in terms of bang/LOC. But it's useful when you need it. |
To support both -Ydelambdafy strategies, look for both inline
(anonfun) and method (lambda) closure classes.
For method (lambda) style, use the anonfun method that is
invoked by the accessor.
Also, the output of javap must be captured eagerly for
filtering for the current target method.