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:
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.
Basically, if I have this:
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: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:
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: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 thego:ImportSpec
nodes - not in theComment
attribute btw, in theDoc
attribute. I'm guessing this is maybe related to #56So 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.