Skip to content

Avoid forcing lambda parameter types in overloading resolution #6132

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 8 commits into from
Mar 27, 2019

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Mar 21, 2019

When taking the typedArgs of a FunProto we now always avoid failing
on untyped parameters of lambdas. Instead we give the parameter a ? type
and continue.

This allows to use lambdas with untyped parameters in more situations
than before.

@odersky
Copy link
Contributor Author

odersky commented Mar 21, 2019

test performance please

1 similar comment
@odersky
Copy link
Contributor Author

odersky commented Mar 21, 2019

test performance please

@dottybot
Copy link
Member

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

@dottybot
Copy link
Member

Performance test finished successfully:

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

Benchmarks is based on merging with master (bb0a1ed)

@odersky odersky force-pushed the change-overload-lambda branch from 3257173 to c6a561c Compare March 22, 2019 14:54
@odersky odersky requested a review from liufengyun March 22, 2019 15:05
Copy link
Contributor

@liufengyun liufengyun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@liufengyun liufengyun assigned odersky and unassigned liufengyun Mar 25, 2019
odersky added 8 commits March 26, 2019 22:20
When taking the `typedArgs` of a `FunProto` we now always avoid failing
on untyped parameters of lambdas. Instead we give the parameter a ? type
and continue.

This allows to use lambdas with untyped parameters in more situations
than before.
With the new context merging technique it's no longer needed. We now
propagate any updates to the context from a FuncProto.typedArg immediately
into the caller context. So no need to check later whether the update
is present.
@odersky odersky force-pushed the change-overload-lambda branch from ccc064c to cd9e7e1 Compare March 26, 2019 21:47
@odersky
Copy link
Contributor Author

odersky commented Mar 26, 2019

test performance please

@dottybot
Copy link
Member

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

@dottybot
Copy link
Member

Performance test finished successfully:

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

Benchmarks is based on merging with master (eecd672)

@odersky odersky merged commit 7e24c14 into scala:master Mar 27, 2019
@allanrenucci allanrenucci deleted the change-overload-lambda branch March 27, 2019 18:17
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.

3 participants