-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Given leaked in outer scope #20071
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
Comments
Annother test case // decoder_1.scala
trait Decoder
object Decoder:
given foo: Int = ???
def bar(using d: M[Decoder]): Any = ???
type M[Y] = Y match
case Decoder => Int // test_2.scala
// should fail, does when compiling at the same time as decoder_2.scala
def test: Unit = bar |
This is a minimization from |
I think the issue has rather to do with match types. Sometimes they are resolved sometimes not, and the implicit scope is different for the two versions. |
I can confirm, that's excactly what happens. |
This is necessary to ensure the implicit scope is consistent when involving match types, since they may or may not have been reduced before implicit search. We can for example get different results when loading from tasty than when in the same run. Fixes scala#20071
This is necessary to ensure the implicit scope is consistent when involving match types, since they may or may not have been reduced before implicit search. We can for example get different results when loading from tasty than when in the same run. Fixes scala#20071
We now try to reduce match types before computing their contributions to an implicit scope. This avoids problems where joint and separate compilations gave different results, as in scala#20071 and scala#15183. Background: If a match type is reducible to a type R the compiler is free to replace the match type with R. That should not affect the implicit scope computation. Consequently, we have to try to reduce match types before computing their contributions to an implicit scope. scala#20071 and scala#15183 are really the same problem. Both used to compile in sequence and both gave an implicit not found error when two files were compiled together. In scala#15183 a weird match type was constructed intentionally, in order to avoid an otherwise necessary given import. That exploited a bug in the compiler which this PR fixes.
We now try to reduce match types before computing their contributions to an implicit scope. This avoids problems where joint and separate compilations gave different results, as in scala#20071 and scala#15183. Background: If a match type is reducible to a type R the compiler is free to replace the match type with R. That should not affect the implicit scope computation. Consequently, we have to try to reduce match types before computing their contributions to an implicit scope. scala#20071 and scala#15183 are really the same problem. Both used to compile in sequence and both gave an implicit not found error when two files were compiled together. In scala#15183 a weird match type was constructed intentionally, in order to avoid an otherwise necessary given import. That exploited a bug in the compiler which this PR fixes.
A related minimisation, where inference rather than implicit search, is impacted by whether or not the match type is reduced. type MyMap[X] <: Any = X match
case Double => Int
def myMap[T]: MyMap[T] = ???
def derived(d: MyMap[Double]): Any = ???
val der = derived(myMap)
But the same code is accepted when moving |
Not sure what to do about this second example. |
Yes indeed, contrarily to the implicit scope situation where making both cases consistently fail was good enough. This also might be related to #18261 |
Both observe different behaviours match type reductions depending on whether they are compiled together or separately. They both compile only with separate compilation.
This already wasn't the case for unpickled match types, which caused varying results for `ImplicitRunInfo#isAnchor`, by not reaching the `isMatchAlias` condition. Ensures both #20071 and #20136 each have the same result, when compiled with a classpath dependency as when merged. Note that they both still fail (20071 compiles but shouldn't), but at least do so consistently. Also update TreeUnpickler MATCHtpt doc to align with changes from #19871 Co-authored-by: Guillaume Martres <[email protected]>
Match types are already not flagged as `Deferred` when unpickled. This caused varying results for `ImplicitRunInfo#isAnchor`, by not reaching the `isMatchAlias` condition when created from the Namer. Ensures both #20071 and #20136 each have the same result, when compiled with a classpath dependency as when merged into a single file. Fixes #20136
Compiler version
3.5.0-RC1-bin-SNAPSHOT
Minimized code
Output
Compiles (but should not)
Expectation
Should not compile.
foo
should not be available intest
witouth an import.The text was updated successfully, but these errors were encountered: