CDT/calls/Indexing20061011

From Eclipsepedia

< CDT‎ | calls
Jump to: navigation, search

Contents

Attendees

  • Symbian - Andrew
  • IBM - Jason, Mike Kucera
  • WindRiver - Markus


Content

Discussion of proposed API

Andrew asks for the role of IIndexFragment: Idea is to separate the PDOM from the index in a way that allows replacing the PDOM implementation. Even if there is currently no plan to do so, it is a good thing to keep things separated. Andrew requests to move the IIndexFragments to an internal package. Agreed.

IBM needs more time to find out whether they have issues with the API or not. So the code will not be committed for another few days so there is time to raise additional issues.

Andrew asks for additional methods in IIndex to allow explicit queries in a single linkage, rather than using the IndexFilter object. I try to keep the API minimal at this point as it is easy to add methods at a later point without breaking clients. It will be hard to remove them, though.

I made a method for converting an ICElement to an IBinding part of the API. It is not yet clear how we will implement it. One solution could be by using the keys for bindings. Another one would pass the ICElements all the way down to the PDOM. Can be decided at a later point.

How to implement methods that require a search scope

Some of the interfaces in the API are taken from the existing API for the AST (e.g.: IBinding, IScope). Objects returned by PDOM have to implement these. For some methods this is not easy, so that they currently return null or throw a PDOMNotImplementedException. There are two reasons why it is hard to implement those:

  • The method makes sense within the AST only. Examples for that are IScope.removeBinding(...) or IScope.addName(...). It is not even a good idea to allow clients to call those. I will remove those from the interface.
  • The method requires a search scope. The best example for that is IScope.find(String name). In case IScope is a namespace the result depends on the scope you are searching in. A single PDOM may not be able to give you the correct answer. Two approaches to this have been discussed:
    • Wrap objects from the PDOM and provide the search context in the wrapper object. Disadvantage is that we have to create additional objects and that we have to duplicate the hierarchy used in the PDOM to implement the correct interfaces. This kind of breaks the separation between PDOM and Index.
    • Change methods requiring a search scope in the interface and add a parameter that allows passing in the search scope.

How to handle duplicate bindings due to multiple PDOMs

We agreed that methods in the index should not return duplicate bindings. To achieve that, a concept of a key for bindings has to be invented. This has to be part of the IIndexFragment API.

Andrew shows confidence that we can also implement a visitor on the index that works similar to the current PDOMVisitor. It may be added at a later point, if needed, currently no visitor is part of the API.

How to handle includes across projects

A source file from project 'A' may include a header found in project 'B'. In case the fast indexer finds the information for the header in PDOM-B it can use it. In case it does not find it, it has to parse the header. This raises the question where it should store the symbol information for the header. In the local PDOM-A or in PDOM-B:

  • Local PDOM-A: This leads to a situation where symbol information for files in project A is actually stored in project B. So if I search for declarations in project B, will I find them?
  • PDOM-B: This is the logical place to store the information. We'd have to handle multiple write-locks (this is possible) and have to think about various combinations of indexers. What if project A uses the fast indexer, but project B the full indexer?

We did not decide this, yet.

A sub-problem here is, that we have to store include-relations across PDOMs.