Proposal: Adding line/column to SourceKit's import declaration's index

Hello guys, please forgive me and feel free to close this thread if this isn't the correct forum for this kind of discussion!

I've been playing a lot with SourceKit's index request for a few of my tools and noticed the lack of some potential features that could benefit tools that rely on SourceKit.

In my tool's case, I'm having a dire need of knowing the line and column of import declarations directly in the index request.

      key.kind: source.lang.swift.import.module.clang, "MyLibrary",
      key.filepath: "path",
      // key.line: 2,
      // key.column: 8

As most entities already provide this info, I thought it wouldn't be too disruptive if the imports also had them. My C++ is rusty, but looking at SwiftIndexing.cpp and its sister files makes me think it's possible to do so without too much trouble.

What do you guys think?

related: SourceKit get 2D character indices (instead of byte indices)

The 'key.dependencies' entries is a set and don't directly correlate to source occurrences, meaning if you have:

import MyLibrary
import MyLibrary

You are going to see one entry for 'MyLibrary' in 'key.dependencies' entries.
But I think it would be useful to add entries to 'key.entities' representing module imports, including line info. For the above example there would be 2 entries, one for each import.

Adding 'key.entities' entries sounds great - If I'm correct, that could also cover explicit library references in code such as:

let foo = Swift.String()

These are also currently not visible in indexSources but feel like a very useful info to identify - at least for my tool.

Yes, that'd be useful!

Do you consider this a Starter task Argyrios? I would love to try to implement this, would just need some file paths and small directions as I never wandered outside the Standard Library.

I think so. Start a JIRA issue and we could iterate.
For module references note that SourceEntityWalker::visitModuleReference() exists as callback but IndexSwiftASTWalker is not overriding it to take advantage of it.