SemanticDB occurrence for default contructor should be zero length

[tgodzik]

Minimized code

class Test(a: Int)
val a = new Test(1)
val b = new Test(2)

Output

SemanticDB occurence:

[1:10..1:18): <- classes/C7#`<init>`().

Expectation

SemanticDB occurence:

[1:10..1:10): <- classes/C7#`<init>`().

[smarter]

Why? The default constructor here is def <init>(a: Int) where (a: Int) comes from user code, and normally when we generate a synthetic tree that contains user-code, its position is the position of the user code.

[tgodzik]

Positions in semanticDB only show the exact symbol name. There is no actual <init> anywhere so we are unable to set the position to it. Additionally, it overlaps with the other occurences for symbols a nad Int and that causes some issues along the way.

[smarter]

Ah OK, so the position you want is the "name position", not the full position of the definition. In Dotty this should be handled by using namePos: https://github.com/lampepfl/dotty/blob/1ab71c10f56cf8ed58546bd1a1bb9f28af746a2b/compiler/src/dotty/tools/dotc/ast/Trees.scala#L351-L355

[bishabosha]

We do still need non zero length spans for most names, and we are already using nameSpan, so should name span have some special cases, like for extension_foo => foo, or should this just be escaped in semanticdb extraction

[smarter]

we are already using nameSpan

So how come the nameSpan of a synthetic constructor isn't empty?

[bishabosha]

https://github.com/lampepfl/dotty/blob/86398747844e559f0c891018b37adcc51a737667/compiler/src/dotty/tools/dotc/ast/Trees.scala#L346
so this appears in the else branch which suggests that the primary constructor is not synthetic

Edit: in the example above the span was length 8 because the primary constructor traversal was not using nameSpan, but when I changed to use nameSpan it was still not zero length

[bishabosha]

secondly i have to manually adjust name span for anonymous definitions, should those have zero nameSpan?

Edit: it also looks like these create zero length nameSpan now

[bishabosha]

This seems to be another case where adding synthetic flag to the primary constructor mods in the parser has strange consequences, so will do the simple option for now