-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Conversation
test performance please |
1 similar comment
test performance please |
performance test scheduled: 1 job(s) in queue, 1 running. |
Performance test finished successfully: Visit http://dotty-bench.epfl.ch/6132/ to see the changes. Benchmarks is based on merging with master (bb0a1ed) |
3257173
to
c6a561c
Compare
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.
LGTM
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.
ccc064c
to
cd9e7e1
Compare
test performance please |
performance test scheduled: 2 job(s) in queue, 1 running. |
Performance test finished successfully: Visit http://dotty-bench.epfl.ch/6132/ to see the changes. Benchmarks is based on merging with master (eecd672) |
When taking the
typedArgs
of aFunProto
we now always avoid failingon 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.