Skip to content

Fix #3352: defaults parameters require named type in compatibility check #3357

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

Closed
wants to merge 1 commit into from

Conversation

liufengyun
Copy link
Contributor

@liufengyun liufengyun commented Oct 20, 2017

Fix #3352: defaults parameters require named type in compatibility check

@liufengyun
Copy link
Contributor Author

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/3357/ to see the changes.

Benchmarks is based on merging with master (e1365d9)

Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

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

I could not find out why the changes fix the problem and do not have a good intuition about possible side effects or effects on performance. Can you add an explanation how this fixes the problem?

…ty check

In implicit search, if the expected type is applying type and the candidate
is a TermRef to a method with default parameters, we need the TermRef
to the method in order for `TestApplication` to insert default parameters.
Otherwise, by widening the TermRef to MethodType, the information about default
parameters is lost,  which may incorrectly disqualify a candidate.
@liufengyun
Copy link
Contributor Author

@odersky : I just updated the PR with more notes. Could you check if there's a better solution to the problem? Thanks.

@odersky
Copy link
Contributor

odersky commented Oct 25, 2017

Thanks for the notes. Now I understand what goes on. I am still not convinced because of the duplication in compatibility checks. This could cost us in complexity and performance. I think it might be better to make normalize not dereference a term type. Let me try this out.

@liufengyun
Copy link
Contributor Author

Superseded by #3386

@liufengyun liufengyun closed this Oct 25, 2017
@liufengyun liufengyun deleted the fix-3352 branch October 25, 2017 20:24
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