> http://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1000989
> http://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1000993

> -- Mirco

> On Aug 4, 2012, at 11:26 AM, Mirco Dotta wrote:

>> On Aug 3, 2012, at 1:53 PM, sschaef wrote:

>>> 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).

>>>> It is indeed complex (also in terms of interaction between the
>>>> different components).

>>>>> Do other parts of the IDE build upon this or is it a more
>>>>> separated part of the IDE?

>>>> 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).
>> However, it needs to interact with the Scala Presentation Compiler
>> and it relies heavily on compilers
>> data-structures (symbols, tree and types). So, I'm sure you'll have
>> some fun, and some interesting
>> challenges ;-)

>> The most important thing to keep in mind is that all compiler's
>> data-structures are *not* thread-safe
>> and hence can't in general be accessed outside of the
>> `PresentationCompilerThread` (this strategy
>> of ensuring thread-safey is known as "thread confinement"). So, every
>> time you see a `ask` or
>> `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....

>>> http://www.assembla.com/spaces/scala-ide/tickets/1000984

>> From 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:

>>> 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 ;-)

>>>>> On 08/02/2012 10:50 PM, Mirco Dotta wrote:

>>>>>> On Jul 29, 2012, at 2:11 AM, sschaef wrote:

>>>>>>> I found another test case which fails:

>>>>>>> package test1

>>>>>>> trait Trait/*ref*/

>>>>>>> class Ref {
>>>>>>>   def meth(t: Trait) = t
>>>>>>> }

>>>>>>> java.lang.AssertionError:
>>>>>>> expected:<TestResult(Clazz(test1.Trait),Set(Method(test1.Ref.meth(test1.Tra it))))>
>>>>>>> but
>>>>>>> was:<TestResult(Clazz(test1.Trait),Set(Method(test1.Ref.Ref())))>

>>>>>>> Test case:
>>>>>>> https://github.com/sschaef/scala-ide/commit/a40935623c11f42429c17d629...

>>>>>>> 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)?

>>>>>> At a high level, here is what happens when you right click on an
>>>>>> identifier in a Scala editor, and then select References > Project:

>>>>>> 1) `ScalaCompilationUnit.codeSelect`
>>>>>> (https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt....)
>>>>>> 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 => IJavaElement, with the following
>>>>>> high-level steps:

>>>>>>     * 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....

>>>>>> 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....),
>>>>>> i.e., the indexer didn't correctly categorized the selected code
>>>>>> element.

>>>>>> (I'm mentioning this for giving you some more context, but I
>>>>>> don't think the indexer is to blame for your failing test)

>>>>>> 2) The `ScalaMatchLocator`
>>>>>> (https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt....)
>>>>>> is the component responsible of reporting the references (or
>>>>>> declarations) that are matches for the search that is being executed.

>>>>>> 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....)
>>>>>> was not correctly updated.

>>>>>> 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....) with
>>>>>> a atOwner(tree.symbol){ ... }, the `enclosingDeclaration` should
>>>>>> be correctly updated and your test will hopefully succeed.

>>>>>> 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!).

>>>>>> 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).
>>>>>> 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 :)

>>>>>>> (The following is what I think I understood):

>>>>>>> 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....).
>>>>>>> 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.

>>>>>>> I would be very happy retrieving explanations of what's going on
>>>>>>> there.

>>>>>> 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.