Fix #1378: Propagate more knowledge of result type into applications #1395
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Error messages were suppressed so far, now get printed.
As observed by @smarter, makes sense to do this.
If an application has functions with implicit parameter types we need to be more aggressive about propagating knowledge of the expected result type into the constraint. Fixes scala#1378.
| // todo: fill with methods from TreeInfo that only apply to untpd.Tree's | ||
| import TreeInfo._ | ||
|
|
||
| def isFunctionWithImplicitParamType(tree: Tree) = tree match { |
There was a problem hiding this comment.
I find the use of implicit in this context confusing, how about unknown instead?
This should have been done in a PR that was merged before.
Interestingly, adding
mutable.BufferLike
to the whitelist succeeds under junit but fails under partest. Unfortunately I can't see
any output in the log indicating what went wrong. I only see this:
!! 306 - pos/compileStdLib [compilation failed]
# Failed test paths (this command will update checkfiles)
test/partest --update-check \
/Users/odersky/workspace/dotty/tests/partest-generated/pos/compileStdLib
|
More info on failing stdlib test: If I run the test alone in partest it succeeds. Unfortunately, this looks like we might have a race. Difficult to say without more test output. I'll make a separate issue #1401 so that we can complete this PR. |
|
See #1401 (comment) for the log of failure in CI. |
|
LGTM |
OlivierBlanvillain
pushed a commit
to OlivierBlanvillain/dotty
that referenced
this pull request
Dec 8, 2016
Generate java signatures for private members as well (scala#1395)
OlivierBlanvillain
pushed a commit
to OlivierBlanvillain/dotty
that referenced
this pull request
Dec 12, 2016
Generate java signatures for private members as well (scala#1395)
smarter
added a commit
to dotty-staging/dotty
that referenced
this pull request
Oct 13, 2021
This was originally added in scala#1395 to make the following compile: (1, x => 2): (Int, Int => Int) But reverting this change doesn't break anything anymore: the other call to `constrainResult` in `Application#init` is enough to propagate the constraint needed to type lambda. The strange thing is that this call already existed before scala#1395, I don't know why it wasn't enough back then.
olsdavis
pushed a commit
to olsdavis/dotty
that referenced
this pull request
Apr 4, 2022
This was originally added in scala#1395 to make the following compile: (1, x => 2): (Int, Int => Int) But reverting this change doesn't break anything anymore: the other call to `constrainResult` in `Application#init` is enough to propagate the constraint needed to type lambda. The strange thing is that this call already existed before scala#1395, I don't know why it wasn't enough back then.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the presence of implicits, this a delicate dance. On the one hand, we need to propagate
knowledge of result types into applications in order to infer parameters as shown in i1378.scala.
On the other hand, we might go down a wrong path with this, if for instance we really meant to insert an implicit on the result type.
Review by @nicolasstucki or @smarter.