Skip to content

Various fixes related to lambda adaptation #3203

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

Merged
merged 4 commits into from
Sep 30, 2017

Conversation

smarter
Copy link
Member

@smarter smarter commented Sep 28, 2017

No description provided.

@smarter smarter force-pushed the fix-lambda-nulls branch 3 times, most recently from 673eaed to 66098d3 Compare September 28, 2017 16:08
@smarter
Copy link
Member Author

smarter commented Sep 28, 2017

test performance please

@dottybot
Copy link
Member

performance test scheduled: 1 job(s) in queue, 0 running.

@nicolasstucki
Copy link
Contributor

Needs rebase

@dottybot
Copy link
Member

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/3203/ to see the changes.

Benchmarks is based on merge(s) with master

@smarter
Copy link
Member Author

smarter commented Sep 28, 2017

Visit http://dotty-bench.epfl.ch/3203/ to see the changes.

@liufengyun I'm getting a 404 on this page

@liufengyun
Copy link
Contributor

liufengyun commented Sep 28, 2017 via email

@smarter
Copy link
Member Author

smarter commented Sep 28, 2017

Same issue with both firefox and chrome, however I don't get a 404 when I use curl or wget.

@smarter
Copy link
Member Author

smarter commented Sep 28, 2017

Hah, it magically works now!

@nicolasstucki
Copy link
Contributor

Needs rebase

When unboxing a null to a value class in Scala, the default value of the
value class should be returned, before this commit an NPE was thrown instead.
Like in scala/scala-java8-compat@d7e0125,
we fix this by using BoxesRunTime, bun we don't use it for boxing
since it's unnecessary.

After this commit, we still throw NPE when unboxing nulls in
unspecialized lambdas called in generic contexts (see if3_unspecialized
in the added test). This is addressed by the next commits in this PR.
This commit does not change the end result of FunctionalInterfaces but
makes the code easier to read, and add a
`Definitions#isSpecializableFunction` method used in the next commit.
Previously, we only created bridges for derived value classes because we
assumed the default adaptation done by LambdaMetaFactory was good
enough. But this is not the case when unboxing null: LMF will throw an
NPE when Scala semantics require using the default value of the value
class instead. We fix this by creating more bridges when needed, this is
similar to the solution adopted in scalac.

Also fixed a bug where adapted closures did not preserve Closure#tpt,
leading to a runtime failure in lambda-sam-bridge.scala
@smarter smarter merged commit aee7a4f into scala:master Sep 30, 2017
@allanrenucci allanrenucci deleted the fix-lambda-nulls branch December 14, 2017 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants