x/tools/go/analysis: change `RelatedInformation` to work without fileset

[hyangah]

RelatedInformation is used to add information related to a diagnostic. Currently it is defined as:

type RelatedInformation struct {
	Pos     token.Pos
	End     token.Pos
	Message string
}

I believe this corresponds to LSP's DiagnosticRelatedInformation and the Pos/End would be translated to LSP Location.

The use of token.Pos in RelatedInformation implies we need to depend on a certain token.FileSet. If the positions of the related information belong to the same package, that's fine. Otherwise, it is awkward to use. For example, I hoped I could annotate reports on functions that transitively call known vulnerable symbols. But the vulnerable symbols may be in different package and we learned about it from Facts generated by the analyzer run on the package.

Will Position be too inefficient?

cc @adonovan @timothy-king

[timothy-king]

So a token.Pos does not make sense in a Fact (as it is relative to a FileSet like you mentioned). Facts need to be deserializable in another process. A token.Position makes a lot more sense in a Fact.

Will Position be too inefficient?

It depends. How many Positions are there? Vulnerable symbols could be encoding a lot of paths so without looking at the implementation it is hard to tell. If it is just diagnostics, there should not be hundreds so this should not be a problem.

The use of token.Pos in RelatedInformation implies we need to depend on a certain token.FileSet. If the positions of the related information belong to the same package, that's fine. Otherwise, it is awkward to use.

This does sound awkward outside of vet. I am not really sure what is helpful here yet. I think I might need to understand some more about how gopls is doing things before I have a strong opinion.

[hyangah]

How many Positions are there?

RelatedInformation is only used for Diagnostics.

Propagating position info using Facts needs different ways if want to be efficient (e.g. for example, one way I am thinking is to encode file paths in package facts, use indexes for object facts, and reconstruct Position with them), but I am sure they shouldn't use RelatedInformation.

I think I might need to understand some more about how gopls is doing things before I have a strong opinion.

@findleyr @pjweinb Can you help us understand how gopls is using this related information from diagnostics?

[timothy-king]

This does sound awkward outside of vet.

To expand a bit, the reason this sounds awkward outside of vet is that {single,multi,unit}checker control their *FileSet. Which simplifies how each would use a Pos.