Handle multiple targets at a given span

[robinp]

A given source code span can contain multiple Kythe anchors, which in turn can target different semantic entities (maybe via different edge types).

On the UI now we have chooseDecorStrategy, that currently chooses the tightest span, or in case of equal lengths, an arbitrary (first) one. (This confusing behavior almost lead to a false bug report in kythe/kythe#4129).

Examples

Definitions

According to the Kythe schema, the definition anchor has (at least) two outgoing edges: defines/binding to the definition entitiy, and completes to the declaration.

• Expectation: when selecting for purposes of getting backrefs, the defines/binding target should take precedence automatically.

Local binding aliasing global thing

As described in kythe/kythe#3934, some languages want both defines/binding to a local thing and a ref to a global thing from the same anchor. For example, TypeScript or Python for from foo import bar imports, or Haskell for f Bar{bar} record puns [1] [2] or positional deconstruction 3.

• Expectation: alternative behavior. UI should offer to show backrefs for the global ref, bringing repository-wide backrefs (including, module paging, the localized usage), or for the defines/binding, bringing backrefs of only the localized usage.

[1]: sidenote, there are separate-anchored variants such as from foo import bar as baz or f Bar{bar = baz} as well, here bar having the ref and baz the defines/binding, the.

[2]: Actually Haskell also has similar-ish import syntax (qualified etc), but on the language-level (GHC level?) there is no separate local binding, it is just sugar. Might make sense to emulate though.

Multi-ref due to ellipsis

For example in Haskell's RecordWildCards, the .. in f Bar{..} brings into scope all of Bar's fields. [1]

• Cool expectation: A really cool UI would expand the actually used fields in-place, thus reducing the case to the above "aliasing" case. A really cool programmer would not use RecordWildCards in the first place though (but the temptation is so hard to resist, and we are not here to judge).

• Alternative expectation: alternative behavior. Give chance to the user to select which reference they want to see. Not as cool though.

[1] Combined with above "aliasing" case, there would actually be multiple refs and defines/bindings. This happens also for blanket-import syntax (see #9).

Subcase: Record-update with punning (or god forbid RecordWildCards)

Assuming data Bar = Bar { foo :: Int, bar :: Int}, the RecordWildCards syntax let foo = 1; bar = 2; in Bar{..} will have (assuming aliasing implemented) at the ellipsis refs to the global fields and refs to the local bindings.

• Cool expectation: again, expanding in-place. The - not so large - difference is that differentiation is between refs of different kind, not between a ref and a defines/binding. A bit more (server-side?) preprocessing would be needed so sensible differentiation can be made to the user about the refs.

Positional constructors

In Haskell, data Bar = Bar Int should - after implementing google/haskell-indexer#104 - at the Int span both have a defines/binding towards the field def, and a ref towards the Int type.

Multiple refs due to ambiguity

For example in Python's case, there could be multiple refs to alternative bindings: see kythe/kythe#3815.

• Expectation: alternative behavior, should let the user choose.

Notes

When we talk about a choice, the UI might also be free to take some smart behavior - if there are not too many choices (say 2), it could sideload both of them and present in parallel? And highlight with different colors.