[nomaster] backports https://github.com/scala/scala/pull/3236 #3280
Conversation
This file contains 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
ICodeReaders, which decompiles JVM bytecode to ICode, was not setting the `recursive` attribute of `IMethod`. This meant that the inliner got into a cycle, repeatedly inlining the recursive call. The method name `filter` was needed to trigger this as the inliner heuristically treats that as a more attractive inlining candidate, based on `isMonadicMethod`. This commit: - refactors the checking / setting of `virtual` - adds this to ICodeReaders - tests the case involving `invokevirtual` I'm not sure how to setup a test that fails without the other changes to `ICodeReader` (for invokestatic and invokespecial).
This reverts commit d2316df. We can't make `_` an illegal identifier -- it's legal in Java, so we must be able to name these Java underscores.
Fix inliner cycle with recursion, separate compilation
Revert ", importable _."
Need `${dist.dir}/lib/scala-partest.jar` for maven publish.
We still don't want to distribute it in the distribution,
but will have to remove it in release script, as 2.10.x's
build hasn't been refactoreded like master's, and I'm not backporting it.
We used to silently skip class files that would exceed the JVM's size limits. While rare, this should still be an error. While I was at it, also included the name of the offending method.
Report error on code size overflow, log method name.
ghost
assigned 
|
review @retronym |
Even though whitebox macros are supposed to be used to produce expansions that refine advertised return types of their macro definitions, sometimes those more precise types aren’t picked up by the typechecker. It all started with Travis generating structural types with macros and noticing that typer needs an extra nudge in order to make generated members accessible to the outside world. I didn’t understand the mechanism of the phenomenon back then, and after some time I just gave up. Afterwards, when this issue had been brought up again in a different StackOverflow question, we discussed it at reflection meeting, figured out that typedBlock provides some special treatment to anonymous classes, and it became clear that the first macro typecheck (the one that types the expansion against the return type of the corresponding macro def) is at fault here. The thing is that if we have a block that stands for a desugard anonymous class instantiation, and we typecheck it with expected type different from WildcardType, then typer isn’t going to include decls of the anonymous class in the resulting structural type: https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L2350. I tried to figure it out at https://groups.google.com/forum/#!topic/scala-internals/eXQt-BPm4i8, but couldn’t dispel the mystery, so again I just gave up. But today I had a profound WAT experience that finally tipped the scales. It turns out that if we typecheck an if, providing a suitable pt, then the resulting type of an if is going to be that pt, even though the lub of the branch types might be more precise. I’m sure that reasons for this behavior are also beyond my understanding, so I decided to sidestep this problem. upd. Here’s Jason’s clarification: Doing thing differently would require us to believe that "'Tis better to have lubbed and lost than never to have lubbed at all." But the desire for efficiency trumps such sentimentality. Now expansions of whitebox macros are first typechecked against pt, the expected type that comes from the enclosing context, before being typechecked against expectedTpe, the expected type that comes from the return type of the macro def. This means that now pt provides the correct expected type for the initial, most important typecheck, which makes types more precise.
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.
Even though whitebox macros are supposed to be used to produce expansions
that refine advertised return types of their macro definitions, sometimes
those more precise types aren’t picked up by the typechecker.
It all started with Travis generating structural types with macros
and noticing that typer needs an extra nudge in order to make generated
members accessible to the outside world. I didn’t understand the mechanism
of the phenomenon back then, and after some time I just gave up.
Afterwards, when this issue had been brought up again in a different
StackOverflow question, we discussed it at reflection meeting, figured out
that typedBlock provides some special treatment to anonymous classes,
and it became clear that the first macro typecheck (the one that types
the expansion against the return type of the corresponding macro def)
is at fault here.
The thing is that if we have a block that stands for a desugard anonymous
class instantiation, and we typecheck it with expected type different from
WildcardType, then typer isn’t going to include decls of the anonymous class
in the resulting structural type: https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L2350.
I tried to figure it out at https://groups.google.com/forum/#!topic/scala-internals/eXQt-BPm4i8,
but couldn’t dispel the mystery, so again I just gave up.
But today I had a profound WAT experience that finally tipped the scales.
It turns out that if we typecheck an if, providing a suitable pt, then
the resulting type of an if is going to be that pt, even though the lub
of the branch types might be more precise. I’m sure that reasons for this
behavior are also beyond my understanding, so I decided to sidestep this problem.
upd. Here’s Jason’s clarification: Doing thing differently would require
us to believe that "'Tis better to have lubbed and lost than never to have
lubbed at all." But the desire for efficiency trumps such sentimentality.
Now expansions of whitebox macros are first typechecked against pt,
the expected type that comes from the enclosing context, before being
typechecked against expectedTpe, the expected type that comes from the return
type of the macro def. This means that now pt provides the correct
expected type for the initial, most important typecheck, which makes
types more precise.