From a quick experiment with -Xprint, it seems that it becomes a "method"
in uncurry. Before that it's printed as _root_, but with -Xprint:uncurry
it's printed as _root_() [1]
The problem is that root package qualifier from root.scala.xml.Null somehow
gets past Typer and later we crash.
adaptToMemberWithArgs is a bit at fault but the underlying cause may be
somewhere else.
On 10 August 2012 22:29, Paul Phillips <pa...@improving.org> wrote:
> The problem is that root package qualifier from root.scala.xml.Null somehow gets past Typer and later we crash.
That's only partially the reason. I only later noticed that we don't (or least weren't in the past) removing the qualifier consistently. It's somewhere in Typers ( not on my laptop atm so cannot give you the location).
Since I never really touched that part I don't know if it is intended or not.
> adaptToMemberWithArgs is a bit at fault but the underlying cause may be somewhere else.
> On 10 August 2012 22:29, Paul Phillips <pa...@improving.org> wrote:
> Can you incur "_root_()" without any xml? I think it's a bug in the xml parser.
Right. Or we could alternatively override isStatic in root symbols (which I
think would be a good idea anyways).
But I want to get to the bottom of it. It seems that typer after
refactoring doesn't strip off RootPackage qualifiers as in "if
(qual1.symbol == RootPackage) treeCopy.Ident(tree1, name) else tree1".
Weird.
On 10 August 2012 23:31, Paul Phillips <pa...@improving.org> wrote:
On Aug 10, 2012, at 11:39 PM, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
> Right. Or we could alternatively override isStatic in root symbols (which I think would be a good idea anyways).
> But I want to get to the bottom of it. It seems that typer after refactoring doesn't strip off RootPackage qualifiers as in "if (qual1.symbol == RootPackage) treeCopy.Ident(tree1, name) else tree1". Weird.
> On 10 August 2012 23:31, Paul Phillips <pa...@improving.org> wrote:
> I don't know what changed, but the simple solution here is to fix isStatic so it is not willing to claim that packages are not static.
Okay found it. `Tree.hasSymbolWhich` is implemented incorrectly. The
offending patch adds a check for this.hasSymbol, which is false for Apply
nodes. Hence _root_ qualifier doesn't get stripped off, and bad things
happen.
On 10 August 2012 23:39, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
> Right. Or we could alternatively override isStatic in root symbols (which
> I think would be a good idea anyways).
> But I want to get to the bottom of it. It seems that typer after
> refactoring doesn't strip off RootPackage qualifiers as in "if
> (qual1.symbol == RootPackage) treeCopy.Ident(tree1, name) else tree1".
> Weird.
> On 10 August 2012 23:31, Paul Phillips <pa...@improving.org> wrote:
>> I don't know what changed, but the simple solution here is to fix
>> isStatic so it is not willing to claim that packages are not static.
Funny! It took a superposition of three oversights (adaptToMember not
removing _root_, _root_ having isStatic set to false and broken
hasSymbolWhich) to blow up. The first two oversights alone were not enough
:)
On 10 August 2012 23:49, Hubert Plociniczak <hubert.plocinic...@epfl.ch>wrote:
> On Aug 10, 2012, at 11:39 PM, Eugene Burmako <eugene.burm...@epfl.ch>
> wrote:
> Right. Or we could alternatively override isStatic in root symbols (which
> I think would be a good idea anyways).
> But I want to get to the bottom of it. It seems that typer after
> refactoring doesn't strip off RootPackage qualifiers as in "if
> (qual1.symbol == RootPackage) treeCopy.Ident(tree1, name) else tree1".
> Weird.
> It's because of context.tree in adaptToMember...
> On 10 August 2012 23:31, Paul Phillips <pa...@improving.org> wrote:
>> I don't know what changed, but the simple solution here is to fix
>> isStatic so it is not willing to claim that packages are not static.
On Fri, Aug 10, 2012 at 2:51 PM, Eugene Burmako <eugene.burm...@epfl.ch>wrote:
> Okay found it. `Tree.hasSymbolWhich` is implemented incorrectly. The
> offending patch adds a check for this.hasSymbol, which is false for Apply
> nodes. Hence _root_ qualifier doesn't get stripped off, and bad things
> happen.
I'm glad I could provide the critical third leg of the bug platform.
I see hasSymbol can just be tossed from hasSymbolWhich entirely. It exists
primarily to avoid all the NPEs one enjoys when depending on everyone to
check .symbol != null every time.
> On Fri, Aug 10, 2012 at 2:51 PM, Eugene Burmako <eugene.burm...@epfl.ch>wrote:
>> Okay found it. `Tree.hasSymbolWhich` is implemented incorrectly. The
>> offending patch adds a check for this.hasSymbol, which is false for Apply
>> nodes. Hence _root_ qualifier doesn't get stripped off, and bad things
>> happen.
> I'm glad I could provide the critical third leg of the bug platform.
> I see hasSymbol can just be tossed from hasSymbolWhich entirely. It
> exists primarily to avoid all the NPEs one enjoys when depending on
> everyone to check .symbol != null every time.
Clearly, root package needs to be static, so that's a bug. I am less sure
about hasSymbolWhich. I think it is correct as defined. If a tree does not
have a symbol (ie hasSymbol is false) then clearly hasSymbolWhich should
also be false. Clients need to take that into account.
> Clearly, root package needs to be static, so that's a bug. I am less sure
> about hasSymbolWhich. I think it is correct as defined. If a tree does not
> have a symbol (ie hasSymbol is false) then clearly hasSymbolWhich should
> also be false. Clients need to take that into account.
> Cheers
> - Martin
>> On 10 August 2012 21:48, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
>>> Sorry, that was a typo. I meant the RootPackage symbol.
>>> This one: final object RootPackage extends ModuleSymbol(rootOwner,
>>> NoPosition, nme.ROOTPKG)
>>> On 10 August 2012 21:40, Paul Phillips <pa...@improving.org> wrote:
>>>> On Fri, Aug 10, 2012 at 12:16 PM, Eugene Burmako <
>>>> eugene.burm...@epfl.ch> wrote:
On Sun, Aug 12, 2012 at 4:09 AM, martin odersky <martin.oder...@epfl.ch>wrote:
> If a tree does not have a symbol (ie hasSymbol is false) then clearly
> hasSymbolWhich should also be false. Clients need to take that into account.
The problem is that what it means to "have a symbol" is ill-defined.
"hasSymbol" would be better called "hasSymbolField" because that's what
the implementation is really testing. However "hasSymbolWhich" is intended
for the generally far more useful question of what happens when you call
.symbol on that tree (but avoiding NPEs.) The difference arises in the
trees which forward the symbol call to some underlying tree, as
Apply/TypeApply do to their first children.
>> Clearly, root package needs to be static, so that's a bug. I am less sure
>> about hasSymbolWhich. I think it is correct as defined. If a tree does not
>> have a symbol (ie hasSymbol is false) then clearly hasSymbolWhich should
>> also be false. Clients need to take that into account.
>> Cheers
>> - Martin
>>> On 10 August 2012 21:48, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
>>>> Sorry, that was a typo. I meant the RootPackage symbol.
>>>> This one: final object RootPackage extends ModuleSymbol(rootOwner,
>>>> NoPosition, nme.ROOTPKG)
>>>> On 10 August 2012 21:40, Paul Phillips <pa...@improving.org> wrote:
>>>>> On Fri, Aug 10, 2012 at 12:16 PM, Eugene Burmako <
>>>>> eugene.burm...@epfl.ch> wrote:
