bblfsh / go-driver

GNU General Public License v3.0
10 stars 9 forks source link

semantic: Discrepancy in handling of imports #58

Open r0mainK opened 4 years ago

r0mainK commented 4 years ago

Basically, if I have this:

package main

import (
    "foo"
    _ "bar"
    . "baz"
    bak_alias "bak"
)

Then in order to get all imports, the xpath query: //uast:Import/Path works, yielding 8 nodes, twice the same ones, and all is good. However, in the case where I have:

package main

import (
    "foo" // foo
    _ "bar" 
    . "baz" 
    bak_alias "bak"
)

Then the same query does not return the foo nodes, as they now have the go:ImportSpec type. You can check that is the case for each import syntax.

Furthermore, if I have a comment directly above an import like here:

package main

import (
     // foo
    "foo" 
    _ "bar" 
    . "baz" 
    bak_alias "bak" 
)

Then the foo nodes also disappear, for the same reasons. This is not the case if I insert a new line between my comment and the import, as in here:

package main

import (
     // foo

    "foo" 
    _ "bar" 
    . "baz" 
    bak_alias "bak" 
)

Furthermore, when querying //uast:Comment in the snippets with the bug, we now get 3 nodes, one in the flat list, and two nested in the go:ImportSpec nodes - not in the Comment attribute btw, in the Doc attribute. I'm guessing this is maybe related to #56

So yeah, this is quite annoying as we are not able to retrieve imports properly. I think the solution is to change the type of the import node to the normalized uast:Import, but I'd like to point out that this again exemplifies issues with comments that we discussed in #56. I don't know if this a proper bug, or a design choice (I'm guessing the former), but I can't help thinking this is because we are intent on providing structure to comments, and, again, I think a simpler and unified approach should be taken, such as a single flat list with positional information.