Received: by 10.180.95.2 with SMTP id dg2mr184171wib.2.1344072422798;
Sat, 04 Aug 2012 02:27:02 -0700 (PDT)
X-BeenThere: scala-ide-dev@googlegroups.com
Received: by 10.180.90.195 with SMTP id by3ls1581811wib.4.gmail; Sat, 04 Aug
2012 02:27:02 -0700 (PDT)
Received: by 10.216.192.22 with SMTP id h22mr232514wen.10.1344072422036;
Sat, 04 Aug 2012 02:27:02 -0700 (PDT)
Received: by 10.216.192.22 with SMTP id h22mr232513wen.10.1344072421987;
Sat, 04 Aug 2012 02:27:01 -0700 (PDT)
Return-Path: <mirco.do...@typesafe.com>
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43])
by gmr-mx.google.com with ESMTPS id hm1si283866wib.3.2012.08.04.02.27.01
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 04 Aug 2012 02:27:01 -0700 (PDT)
Received-SPF: pass (google.com: domain of mirco.do...@typesafe.com designates 74.125.82.43 as permitted sender) client-ip=74.125.82.43;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of mirco.do...@typesafe.com designates 74.125.82.43 as permitted sender) smtp.mail=mirco.do...@typesafe.com
Received: by wgbdr1 with SMTP id dr1so1137041wgb.24
for <scala-ide-dev@googlegroups.com>; Sat, 04 Aug 2012 02:27:01 -0700 (PDT)
d=google.com; s=20120113;
h=from:mime-version:content-type:subject:date:in-reply-to:to
:references:message-id:x-mailer:x-gm-message-state;
bh=IJcQcvLCxt5dqlCmS/4eQjPz3hJyANW+ZQ6MqCkgTlc=;
b=plaXnTS/enpTWs8nVHjPA13Vr41TqfSG0Umy/M1meMmggZ2F/U1QHfdCnCAudD3yb6
iIdLFr1Glhjhq651ElUDdtLSGPQWxG1ZbErN9Zk+PE++3JiI/zDj+rglZPiYvbHk55sX
PNVxH9uzs3lwswJHFOQU5UpQ+wOP5dnLJOA54GLd/1itWbjBHl6+v6TmwnkU6S5jAytw
O6cjgSrPbi/8yqkrPR6s7z+aq26kQc5AKncJYe+s2EeR8UYzVJxjPwqHM/O6B7HmBLcJ
a7qiAxB6rpDJRTgrUPUEu2dQqVPwR5XQtOXw+B8+o1/MX4LU0IRbAGdf2VeaWG0jS1bs
/B2A==
Received: by 10.180.84.164 with SMTP id a4mr3143178wiz.12.1344072421751;
Sat, 04 Aug 2012 02:27:01 -0700 (PDT)
Return-Path: <mirco.do...@typesafe.com>
Received: from [192.168.1.58] (171-42.4-85.cust.bluewin.ch. [85.4.42.171])
by mx.google.com with ESMTPS id ck9sm3419348wib.2.2012.08.04.02.26.49
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 04 Aug 2012 02:26:58 -0700 (PDT)
From: Mirco Dotta <mirco.do...@typesafe.com>
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_325B9714-E5A1-4071-B108-5B6C10A31DB3"
Subject: Re: [scala-ide-dev] How to execute a single test?
Date: Sat, 4 Aug 2012 11:26:04 +0200
In-Reply-To: <501BBBBF.7060...@antoras.de>
To: scala-ide-dev@googlegroups.com
References: <500EA394.5060...@antoras.de> <CAOBkoFXiTXc2Q=coYJPOtYLUiSVQGmMuFERrka+qNS9EP4C...@mail.gmail.com> <54826121-88c4-439e-a83c-015d82ca49a1@googlegroups.com> <4a24460c-120e-4554-ada3-21c72c8abc6a@googlegroups.com> <500F26E2.4030...@antoras.de> <8dd03cd8-6d80-438e-9271-3ac3ae0bc9f6@googlegroups.com> <5011B092.7020...@antoras.de> <CAOwe9fZWbDSgDay=qPD5gghS=xV58xH2ftOh4WUvjw9vhGh...@mail.gmail.com> <5012BA10.7080...@antoras.de> <88FA05D9-399A-408B-81E6-FE30D5EB5...@typesafe.com> <5012DEC2.4060...@antoras.de> <A1F91472-EE20-4CB3-8DA9-6109E8FEA...@typesafe.com> <50147FB1.7090...@antoras.de> <E2166332-1A1A-4239-908D-678E22F9A...@typesafe.com> <501B9833.9080...@antoras.de> <E0527580-54DE-42A6-B962-500FEBD0B...@typesafe.com> <501BBBBF.7060...@antoras.de>
Message-Id: <94E0E7CE-19D6-443D-9CB6-911222E2D...@typesafe.com>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQlZjTCMzz5r6/v7FXBpAugTNKSa24tbV4uI2CAz8qrR8iu0Onh/u03UMZZxuE6BgDEdPSRy
--Apple-Mail=_325B9714-E5A1-4071-B108-5B6C10A31DB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On Aug 3, 2012, at 1:53 PM, sschaef wrote:
>=20
> On 08/03/2012 11:29 AM, Mirco Dotta wrote:
>>> I don't know how important it is to understand how the classes in =
javaelements (or the part which is used by the find reference feature) =
works. I noticed that this package is one of the most complex parts of =
the complete IDE (measured in lines of code).
>>=20
>> It is indeed complex (also in terms of interaction between the =
different components).
>>=20
>>> Do other parts of the IDE build upon this or is it a more separated =
part of the IDE?
>>=20
>> Absolutely not. Do you have any idea on what you'd like to work on?
> No, I have absolutely not. But this is good - it makes it more =
fascinating for me to work on. ;)
>> If you have a small selection of tickets that you consider =
interesting, I could sort them according to their complexity (well, =
maybe it's better to say the perceived complexity :)).
> Ok, some things bothered me with the current code completion and =
semantic highlighting.
Semantic Highlighting is a relatively small module (for sure compared to =
the JDT search engine).=20
However, it needs to interact with the Scala Presentation Compiler and =
it relies heavily on compilers=20
data-structures (symbols, tree and types). So, I'm sure you'll have some =
fun, and some interesting=20
challenges ;-)
The most important thing to keep in mind is that all compiler's =
data-structures are *not* thread-safe=20
and hence can't in general be accessed outside of the =
`PresentationCompilerThread` (this strategy=20
of ensuring thread-safey is known as "thread confinement"). So, every =
time you see a `ask` or=20
`askOption`, the enclosed block is executed within the =
`PresentationCompilerThread`.
Have a look at the classes here: =
https://github.com/scala-ide/scala-ide/tree/master/org.scala-ide.sdt.core/=
src/scala/tools/eclipse/semantichighlighting/classifier
> http://www.assembla.com/spaces/scala-ide/tickets/1000984
=46rom the ticket description, this looks like a syntax highlighting =
issue, and not a semantic one (because while is a keyword). This could =
be a easy one to fix, but I can't tell for sure :)
> http://www.assembla.com/spaces/scala-ide/tickets/1001171
I like this one, the only difficulty will be to find a way to correctly =
categorize extractors (I don't think there is a symbol or a flag for =
them).
> http://www.assembla.com/spaces/scala-ide/tickets/1001172
I'm not sure if this can be done with the current infrastructure. It =
should be checked (if you want I can have a look and let you know).
> http://www.assembla.com/spaces/scala-ide/tickets/1001176
Hopefully this can be fixed without too many changes, but I can't say =
for sure. You'll have to experiment.
> For code completion I had a lot of ideas but it seems there are no =
easy to fix tickets:
>=20
> http://www.assembla.com/spaces/scala-ide/tickets/1000569
> http://www.assembla.com/spaces/scala-ide/tickets/1001191
> http://www.assembla.com/spaces/scala-ide/tickets/1001192
I have to run now, I'll have a look at those tomorrow or Monday ;-)
>=20
>>=20
>>>=20
>>> On 08/02/2012 10:50 PM, Mirco Dotta wrote:
>>>>=20
>>>> On Jul 29, 2012, at 2:11 AM, sschaef wrote:
>>>>=20
>>>>> I found another test case which fails:
>>>>>=20
>>>>> package test1
>>>>>=20
>>>>> trait Trait/*ref*/
>>>>>=20
>>>>> class Ref {
>>>>> def meth(t: Trait) =3D t
>>>>> }
>>>>>=20
>>>>> java.lang.AssertionError: =
expected:<TestResult(Clazz(test1.Trait),Set(Method(test1.Ref.meth(test1.Tr=
ait))))> but =
was:<TestResult(Clazz(test1.Trait),Set(Method(test1.Ref.Ref())))>
>>>>>=20
>>>>> Test case: =
https://github.com/sschaef/scala-ide/commit/a40935623c11f42429c17d629ce64e=
48eadb9688
>>>>>=20
>>>>> I tried to solve it, but give it up after some hours of debugging =
time noticing that I do not understand how the hell changes are handled =
in the underlying system. There are plenty methods not returning =
anything but continuously producing side effects ... what is going on =
there? Can someone tell me how to detect a control flow there (in the =
classes of scala.tools.eclipse.javaelements)?
>>>>=20
>>>> At a high level, here is what happens when you right click on an =
identifier in a Scala editor, and then select References > Project:=20
>>>>=20
>>>> 1) `ScalaCompilationUnit.codeSelect` =
(https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core=
/src/scala/tools/eclipse/javaelements/ScalaCompilationUnit.scala#L179) =
is called. This method is responsible of locating the code element =
(i.e., one of the subclasses of `SourceRefElement`, which I mentioned =
in one of the previous emails) at the selected position where the search =
action has been triggered. Basically, it's a function Position =3D> =
IJavaElement, with the following high-level steps:
>>>>=20
>>>> * Retrieve the Scala AST Tree node for the passed Position
>>>> * Take the Tree's symbol
>>>> * Call `ScalaJavaMapper.getJavaElement` to convert the Symbol =
into a IJavaElement: =
https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core/=
src/scala/tools/eclipse/javaelements/ScalaJavaMapper.scala#L25
>>>>=20
>>>> If a code element cannot be found (i.e., the result of =
`ScalaCompilationUnit.codeSelect` is an empty array), it usually means =
that there is a bug in the `ScalaIndexBuilder` =
(https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core=
/src/scala/tools/eclipse/javaelements/ScalaIndexBuilder.scala), i.e., =
the indexer didn't correctly categorized the selected code element.=20
>>>>=20
>>>> (I'm mentioning this for giving you some more context, but I don't =
think the indexer is to blame for your failing test)
>>>>=20
>>>> 2) The `ScalaMatchLocator` =
(https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core=
/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala) is the =
component responsible of reporting the references (or declarations) that =
are matches for the search that is being executed.
>>>>=20
>>>> In your failing test, the reference match is found, but it is =
associated with the wrong declaration (the Ref's constructor is reported =
instead of the method Ref.meth). That means that the current =
`enclosingDeclaration` =
(https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core=
/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala#L89) was =
not correctly updated.
>>>>=20
>>>> What I think is happening is that `report(tree)` (where in your =
specific case the Tree is a DefDef) is called *before* updating the =
`enclosingDeclaration`. I believe that if you surround the following =
block =
(https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core=
/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala#L291) with =
a atOwner(tree.symbol) {
>>>> ... }, the `enclosingDeclaration` should be =
correctly updated and your test will hopefully succeed.
>>>>=20
>>>> If that works, and all tests pass, this could be an ok fix for the =
moment. But, I think that it would be even better if we could refactor =
and extract a proper TreeTraverser class whose responsibility would be =
to correctly update the `enclosingDeclaration`. The problem is that =
right now I can't spend any time on improving find references :( I hate =
this, because you have been really doing a wonderful job (man, you learn =
fast!).
>>>>=20
>>>> If you want to keep working on this, I'll do my very best to answer =
your questions, but I can't promise I'll be always responsive. =
Alternatively, you could work on something different for a while (I'm =
sure we can find something a bit more self-contained that you'd be =
interested in contributing. And, maybe, you already have some idea) and, =
once I am back working on find references, we could continue to =
collaborate (I'd be glad of keep working together on this).=20
>>>> I'm really ok with both options, my main concern is making sure you =
don't get frustrated by the lack of feedback, or the daunting codebase, =
or both :)
>>>>=20
>>>>> (The following is what I think I understood):
>>>>>=20
>>>>> It seems that the reference to trait `Trait` is handled in method =
`Ref.meth` in `ScalaMatchLocator.reportTypeReference` =
(https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core=
/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala#L354). It =
is one of the many methods starting with `report` and producing heavily =
side effects. For me they represent a impenetrable network of method =
calls.
>>>>>=20
>>>>> I would be very happy retrieving explanations of what's going on =
there.
>>>>=20
>>>> I hope my above explanations will help you get a better picture of =
what is going on. I am very aware that this part of the codebase is =
quite intimidating.
>>>>=20
>>>=20
>>=20
>=20
--Apple-Mail=_325B9714-E5A1-4071-B108-5B6C10A31DB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Aug 3, 2012, at 1:53 PM, sschaef wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">
=20
<meta content=3D"text/html; charset=3DISO-8859-1" =
http-equiv=3D"Content-Type">
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<div class=3D"moz-cite-prefix">On 08/03/2012 11:29 AM, Mirco Dotta
wrote:<br>
</div>
<blockquote =
cite=3D"mid:E0527580-54DE-42A6-B962-500FEBD0B...@typesafe.com" =
type=3D"cite">
<div>
<blockquote type=3D"cite">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">I don't know how
important it is to understand how the classes in
javaelements (or the part which is used by the find
reference feature) works. I noticed that this package is one
of the most complex parts of the complete IDE (measured in
lines of code). </div>
</blockquote>
<div><br>
</div>
<div>It is indeed complex (also in terms of interaction between
the different components).</div>
<br>
<blockquote type=3D"cite">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">Do other parts of =
the
IDE build upon this or is it a more separated part of the
IDE?<br>
</div>
</blockquote>
<div><br>
</div>
<div>Absolutely not. Do you have any idea on what you'd like to
work on?</div>
</div>
</blockquote>
No, I have absolutely not. But this is good - it makes it more
fascinating for me to work on. ;)<br>
<blockquote =
cite=3D"mid:E0527580-54DE-42A6-B962-500FEBD0B...@typesafe.com" =
type=3D"cite">
<div>
<div>If you have a small selection of tickets that you consider
interesting, I could sort them according to their complexity
(well, maybe it's better to say the perceived complexity =
:)).</div>
</div>
</blockquote>
Ok, some things bothered me with the current code completion and
semantic =
highlighting.<br></div></blockquote><div><br></div><div>Semantic =
Highlighting is a relatively small module (for sure compared to the JDT =
search engine). </div><div>However, it needs to interact with the =
Scala Presentation Compiler and it relies heavily on =
compilers </div><div>data-structures (symbols, tree and types). So, =
I'm sure you'll have some fun, and some =
interesting </div><div>challenges ;-)</div><div><br></div><div>The =
most important thing to keep in mind is that all compiler's =
data-structures are *not* thread-safe </div><div>and =
hence can't in general be accessed outside of the =
`PresentationCompilerThread` (this strategy </div><div>of =
ensuring thread-safey is known as "thread confinement"). So, =
every time you see a `ask` or </div><div>`askOption`, the =
enclosed block is executed within the =
`PresentationCompilerThread`.</div><div><br></div><div>Have a look at =
the classes here: <a =
href=3D"https://github.com/scala-ide/scala-ide/tree/master/org.scala-ide.s=
dt.core/src/scala/tools/eclipse/semantichighlighting/classifier">https://g=
ithub.com/scala-ide/scala-ide/tree/master/org.scala-ide.sdt.core/src/scala=
/tools/eclipse/semantichighlighting/classifier</a></div><div><br></div><br=
><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><a =
class=3D"moz-txt-link-freetext" =
href=3D"http://www.assembla.com/spaces/scala-ide/tickets/1000984">http://w=
ww.assembla.com/spaces/scala-ide/tickets/1000984</a><br></div></blockquote=
><div><br></div><div>=46rom the ticket description, this looks like a =
syntax highlighting issue, and not a semantic one (because while is a =
keyword). This could be a easy one to fix, but I can't tell for sure =
:)</div><br><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" =
text=3D"#000000">
<a class=3D"moz-txt-link-freetext" =
href=3D"http://www.assembla.com/spaces/scala-ide/tickets/1001171">http://w=
ww.assembla.com/spaces/scala-ide/tickets/1001171</a><br></div></blockquote=
><div><br></div><div>I like this one, the only difficulty will be to =
find a way to correctly categorize extractors (I don't think there is a =
symbol or a flag for them).</div><br><blockquote type=3D"cite"><div =
bgcolor=3D"#FFFFFF" text=3D"#000000">
<a class=3D"moz-txt-link-freetext" =
href=3D"http://www.assembla.com/spaces/scala-ide/tickets/1001172">http://w=
ww.assembla.com/spaces/scala-ide/tickets/1001172</a></div></blockquote><di=
v><br></div><div>I'm not sure if this can be done with the current =
infrastructure. It should be checked (if you want I can have a look and =
let you know).</div><br><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF"=
text=3D"#000000">
<a class=3D"moz-txt-link-freetext" =
href=3D"http://www.assembla.com/spaces/scala-ide/tickets/1001176">http://w=
ww.assembla.com/spaces/scala-ide/tickets/1001176</a><br></div></blockquote=
><div><br></div><div>Hopefully this can be fixed without too many =
changes, but I can't say for sure. You'll have to =
experiment.</div><br><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" =
text=3D"#000000">For code completion I had a lot of ideas but it seems =
there are no
easy to fix tickets:<br>
<br>
<a class=3D"moz-txt-link-freetext" =
href=3D"http://www.assembla.com/spaces/scala-ide/tickets/1000569">http://w=
ww.assembla.com/spaces/scala-ide/tickets/1000569</a><br>
<a class=3D"moz-txt-link-freetext" =
href=3D"http://www.assembla.com/spaces/scala-ide/tickets/1001191">http://w=
ww.assembla.com/spaces/scala-ide/tickets/1001191</a><br>
<a class=3D"moz-txt-link-freetext" =
href=3D"http://www.assembla.com/spaces/scala-ide/tickets/1001192">http://w=
ww.assembla.com/spaces/scala-ide/tickets/1001192</a></div></blockquote><di=
v><br></div><div>I have to run now, I'll have a look at those tomorrow =
or Monday ;-)</div><br><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" =
text=3D"#000000">
<br>
<blockquote =
cite=3D"mid:E0527580-54DE-42A6-B962-500FEBD0B...@typesafe.com" =
type=3D"cite">
<div><br>
<blockquote type=3D"cite">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> <br>
<div class=3D"moz-cite-prefix">On 08/02/2012 10:50 PM, Mirco
Dotta wrote:<br>
</div>
<blockquote =
cite=3D"mid:E2166332-1A1A-4239-908D-678E22F9A...@typesafe.com" =
type=3D"cite"><br>
<div>
<div>On Jul 29, 2012, at 2:11 AM, sschaef wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<meta content=3D"text/html; charset=3DISO-8859-1" =
http-equiv=3D"Content-Type">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> I found =
another
test case which fails:<br>
<br>
package test1<br>
<br>
trait Trait/*ref*/<br>
<br>
class Ref {<br>
def meth(t: Trait) =3D t<br>
}<br>
<br>
java.lang.AssertionError:
=
expected:<TestResult(Clazz(test1.Trait),Set(Method(test1.Ref.meth(test1=
.Trait))))>
but
=
was:<TestResult(Clazz(test1.Trait),Set(Method(test1.Ref.Ref())))><br=
>
<br>
Test case: <a moz-do-not-send=3D"true" =
class=3D"moz-txt-link-freetext" =
href=3D"https://github.com/sschaef/scala-ide/commit/a40935623c11f42429c17d=
629ce64e48eadb9688">https://github.com/sschaef/scala-ide/commit/a40935623c=
11f42429c17d629ce64e48eadb9688</a><br>
<br>
I tried to solve it, but give it up after some hours
of debugging time noticing that I do not understand
how the hell changes are handled in the underlying
system. There are plenty methods not returning
anything but continuously producing side effects ...
what is going on there? Can someone tell me how to
detect a control flow there (in the classes of
scala.tools.eclipse.javaelements)?<br>
</div>
</blockquote>
<div><br>
</div>
<div>At a high level, here is what happens when you
right click on an identifier in a Scala editor, and
then select References > Project: </div>
<div><br>
</div>
<div>1) `ScalaCompilationUnit.codeSelect` (<a =
moz-do-not-send=3D"true" =
href=3D"https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.s=
dt.core/src/scala/tools/eclipse/javaelements/ScalaCompilationUnit.scala#L1=
79">https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.c=
ore/src/scala/tools/eclipse/javaelements/ScalaCompilationUnit.scala#L179</=
a>)
is called. This method is responsible of locating the
code element (i.e., one of the subclasses of
`SourceRefElement`, which I mentioned in one of =
the
previous emails) at the selected position where the
search action has been triggered. Basically, it's a
function Position =3D> IJavaElement, with the
following high-level steps:</div>
<div>
<div><br>
</div>
<div> * Retrieve the Scala AST Tree node =
for the
passed Position</div>
<div> * Take the Tree's symbol</div>
<div> * =
Call `ScalaJavaMapper.getJavaElement` to
convert the Symbol into a IJavaElement: <a =
moz-do-not-send=3D"true" =
href=3D"https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.s=
dt.core/src/scala/tools/eclipse/javaelements/ScalaJavaMapper.scala#L25">ht=
tps://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core/sr=
c/scala/tools/eclipse/javaelements/ScalaJavaMapper.scala#L25</a></div>
<div><br>
</div>
<div>If a code element cannot be found (i.e., the
result of `ScalaCompilationUnit.codeSelect` is =
an
empty array), it usually means that there is a bug
in the `ScalaIndexBuilder` (<a =
moz-do-not-send=3D"true" =
href=3D"https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.s=
dt.core/src/scala/tools/eclipse/javaelements/ScalaIndexBuilder.scala">http=
s://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core/src/=
scala/tools/eclipse/javaelements/ScalaIndexBuilder.scala</a>),
i.e., the indexer didn't correctly categorized the
selected code element. </div>
<div><br>
</div>
<div>(I'm mentioning this for giving you some more
context, but I don't think the indexer is to blame
for your failing test)</div>
<div><br>
</div>
<div>2) The `ScalaMatchLocator` (<a =
moz-do-not-send=3D"true" =
href=3D"https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.s=
dt.core/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala">http=
s://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core/src/=
scala/tools/eclipse/javaelements/ScalaMatchLocator.scala</a>)
is the component responsible of reporting the
references (or declarations) that are matches for
the search that is being executed.</div>
<div><br>
</div>
<div>In your failing test, the reference match is
found, but it is associated with the wrong
declaration (the Ref's constructor is reported
instead of the method Ref.meth). That means that the
current `enclosingDeclaration` (<a =
moz-do-not-send=3D"true" =
href=3D"https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.s=
dt.core/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala#L89">=
https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core/=
src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala#L89</a>)
was not correctly updated.</div>
<div><br>
</div>
<div>What I think is happening is that `report(tree)`
(where in your specific case the Tree is a DefDef)
is called *before* updating the
`enclosingDeclaration`. I believe that if you
surround the following block (<span =
class=3D"Apple-tab-span" style=3D"white-space: pre; "><a =
moz-do-not-send=3D"true" =
href=3D"https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.s=
dt.core/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala#L291"=
>https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core=
/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala#L291</a></sp=
an>) with
a <span class=3D"Apple-style-span" =
style=3D"font-family:
monospace; white-space: pre; "><span =
class=3D"n">atOwner</span></span><span class=3D"Apple-style-span" =
style=3D"font-family:
monospace; white-space: pre; "><span =
class=3D"o">(</span></span><span class=3D"Apple-style-span" =
style=3D"font-family:
monospace; white-space: pre; "><span =
class=3D"n">tree</span></span><span class=3D"Apple-style-span" =
style=3D"font-family:
monospace; white-space: pre; "><span =
class=3D"o">.</span></span><span class=3D"Apple-style-span" =
style=3D"font-family:
monospace; white-space: pre; "><span =
class=3D"n">symbol</span></span><span class=3D"Apple-style-span" =
style=3D"font-family:
monospace; white-space: pre; "><span =
class=3D"o">)</span></span><span class=3D"Apple-style-span" =
style=3D"font-family:
monospace; white-space: pre; "> </span><span =
class=3D"Apple-style-span" style=3D"font-family:
monospace; white-space: pre; "><span class=3D"o">{
... }</span></span>, the `enclosingDeclaration`
should be correctly updated and your test will
hopefully succeed.</div>
<div><br>
</div>
<div>If that works, and all tests pass, this could be
an ok fix for the moment. But, I think that it would
be even better if we could refactor and extract a
proper TreeTraverser class whose responsibility
would be to correctly update the
`enclosingDeclaration`. The problem is that =
right
now I can't spend any time on improving find
references :( I hate this, because you have been
really doing a wonderful job (man, you learn =
fast!).</div>
<div><br>
</div>
<div>If you want to keep working on this, I'll do my
very best to answer your questions, but I can't
promise I'll be always responsive. Alternatively,
you could work on something different for a while
(I'm sure we can find something a bit more
self-contained that you'd be interested in
contributing. And, maybe, you already have some
idea) and, once I am back working on find
references, we could continue to collaborate (I'd be
glad of keep working together on this). </div>
<div>I'm really ok with both options, my main concern
is making sure you don't get frustrated by the lack
of feedback, or the daunting codebase, or both =
:)</div>
<div><br>
</div>
</div>
<blockquote type=3D"cite">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">(The =
following
is what I think I understood):<br>
<br>
It seems that the reference to trait `Trait` is
handled in method `Ref.meth` in
`ScalaMatchLocator.reportTypeReference` (<a =
moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext" =
href=3D"https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.s=
dt.core/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala#L354"=
>https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core=
/src/scala/tools/eclipse/javaelements/ScalaMatchLocator.scala#L354</a>).
It is one of the many methods starting with `report`
and producing heavily side effects. For me they
represent a impenetrable network of method =
calls.<br>
<br>
I would be very happy retrieving explanations of
what's going on there.<br>
</div>
</blockquote>
<div><br>
</div>
<div>I hope my above explanations will help you get a
better picture of what is going on. I am very aware
that this part of the codebase is quite =
intimidating.</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</blockquote></div><br></body></html>=
--Apple-Mail=_325B9714-E5A1-4071-B108-5B6C10A31DB3--
Message from discussion How to execute a single test?
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |