Disable -Ydelambdafy:method for specialized FunctionN#4367
Disable -Ydelambdafy:method for specialized FunctionN#4367adriaanm merged 1 commit intoscala:2.11.xfrom
Conversation
|
It looks like this failure is legit: |
d077196 to
f4a2528
Compare
|
That was a newly added test in the category of test that "I updated some tests that intend to test the delambdafy transform to avoid use of specialized function types." I've just changed it to use a non-specialized function so that delambdafy is still used. |
f4a2528 to
826f56c
Compare
|
Just tweaked another of a test that intends to exercise |
|
/rebuild I'm not sure why those tests are failing. |
There was a problem hiding this comment.
I don't recall. Maybe it is for custom pipelines like ScalaJS.
There was a problem hiding this comment.
If it's not clear why it's needed, should we remove it? This kind of code is hard to remove later on because everybody fears some hard to predict breakage.
The Delambdafy phase generates its `FunctionN` subclasses after the specialization phase. As such, `((x: Int) => x).apply(42)` incurs boxing. This commit falls back to the `-Ydelambdafy:inline` in this case. This is done by running the specialization type map over the type of the function, and seeing if anything changes. To make this work robustly, we first need to ensure that the specialization info transformer has processed all the function types. This is not a fundamental limitation; we could in principle generate the specialized code. A followup change will use `-Ydelambdafy:method` as the basis for invokedymnamic lambdas. As part of that stream of work, we will synthesize specialization-aware lambdas, and remove the fallback to `-Ydelambdafy:inline`. I have updated some tests that intend to test the delambdafy transform to avoid use of specialized function types.
8db3ef9 to
ea61b3f
Compare
|
@gkossakowski By removing that condition, I found that a test case using |
|
LGTM -- Merging to unlock next steps. There's a small typo btw. Left as exercise for the submitter :) |
Disable -Ydelambdafy:method for specialized FunctionN
|
I was just about to hit the merge button, @retronym -- meant to do sooner, sorry. |
|
PS: canUseDelam_b_dafyMethod |
The Delambdafy phase generates its
FunctionNsubclasses afterthe specialization phase. As such,
((x: Int) => x).apply(42)incursboxing.
This commit falls back to the
-Ydelambdafy:inlinein this case.This is done by running the specialization type map over the
type of the function, and seeing if anything changes. To make this
work robustly, we first need to ensure that the specialization info
transformer has processed all the function types.
This is not a fundamental limitation; we could in principle generate
the specialized code.
A followup change will use
-Ydelambdafy:methodas the basis forinvokedymnamic lambdas. As part of that stream of
work, we will synthesize specialization-aware lambdas, and remove
the fallback to
-Ydelambdafy:inline.Review by @gkossakowski
I have updated some tests that indend to test the delambdafy transform
to avoid use of specialized function types.