| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attempt to placate pos/t4970.scala in 55c6fd4 roused another
dragon.
We've got two levers here: the type of the symbol of the outer
accessor, and the type of its DefDef.
They have been historically out of sync due to the vaguaries of
finalResultType (which is far less vague since 671e6e03c7), but
the finicky operation of ExplicitOuter now has a hard time when
we try to bring them into line.
This stuff is notoriously difficult to understand because the
trees you see from `-Xprint` show a tpt derived from the method
symbol's info, and discards the actual tpt in the tree.
Rather than letting `DefDef(acc)` call `TypeTree(sym)` and use
`sym.tpe_*.finalResultType`, this commit computes the member type
of the accessor from the current class and explicitly uses that as
the return type of the outer accessor def.
We should try to push this a little deeper. I tried to put it into
`def TypeTree`, but that broke, among others,
run/concurrent-stream.scala. Maybe `def DefDef` and `def ValDef`?
But a localised fix is the right start as it addresses the regression
in a minimal fashion to get the IDE building again.
|
| |
|
|
|
| |
This is the key ingredient so TypeTree(sym) can resist
widening the type.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The implementation had come to depend on finalResultType
accidentally doing things beyond its charter - in particular,
widening types. After hunting down and fixing the call sites
depending on the bugs, I was able to rewrite the method to do
only what it's supposed to do.
I threw in a different way of writing it entirely to suggest how
some correctness might be obtained in the future. It's a lot
harder for a method written like this to break.
|
| |
|
|
|
|
|
|
|
| |
Quieted down many logging statements which contribute
disproportionate noise. Made others emit something more sensible.
Spent lots of time on the inliner trying to find a regular
format to make the logs more readable. Long way to go here but
it'd be so worth it to have readable logs instead of mind-numbing
indiscriminate text dumps.
|
| | |
|
|
|
It's more of a "dump what it says to a file so we'll know if
any of this ever changes" than a "test" per se. It could use
some wheat/chaff/nonsense/sense sorting. Still, it would
be great to have more stuff like this.
|
