[Go] Fix compiler directive syntax patterns

[kortschak]

This adds line and export directive syntax patterns and generalises the //go:name pattern for use in other contexts such as linter directives. It also fixes //go:name matching to avoid matching invalid directive comments.

It's not completely clear to me how to express the expectation in the tests (and some current tests expectation are incorrect; //go and //go: are invalid directives — so I expect tests to fail), so please let me know what I should add.

These should be marked as valid directives:

//go:linkname
//go:cgo_import_dynamic
//lint:ignore U1000 This is here for user documentation.
//lint:ignore-file Autogenerated.
//line file.rl:3732:45
//line :3732:45:45
//line :3732 :45:45
/*line file.rl:3732:45*/
/*line :3732:45:45*/
/*line :3732 :45:45*/
//export myfunc
//extern myfunc

These should not be marked:

/*line file.rl:3732:45 */
/*line :3732:45:45 */
/*line :3732 :45:45 */
//go:
//go

Please take a look.

[jrappen]

In general, capturing regex groups should not be part of variables in the syntax. This is mainly for readability reasons.

Instead use the variables within a capturing group of the match in the contexts.

[jrappen]

Additionally, you should probably add "negative tests" for the examples listed above, where markings should not be applied.

Edit: I somehow didn't see the negative tests for //go and //go: towards the top of the suggested changes.

[kortschak]

Additionally, you should probably add "negative tests" for the examples listed above, where markings should not be applied.

These are included.

[kortschak]

In general, capturing regex groups should not be part of variables in the syntax. This is mainly for readability reasons.

In this case (line directive) this either declarifies the use site or breaks the rationale for the pattern, but I will change it.

[jrappen]

This seems fine. I don't use Go, though.

[kortschak]

Looking at golang/go#43776, and noting the existence of //go-sumtype: as a namespace, I think it's worth generalising the pattern.

[deathaxe]

I'd vote to avoid stacking meta.annotation and meta.annotation.parameters. Added a proposal to the branch accordingly. Feel free to further tweak it.

[kortschak]

Please revert c41f4ea, it was better before that, or alternatively (preferably) have a punctuation for the space (I looked for whether there would be an obvious way to specify a space as punctuation, but I could not see a label that fit).

Pattern like so ((//)(line)( ))([a-zA-Z0-9. :]*(?::[0-9]+){1,2})$\n?

[deathaxe]

We could scope whitespace as punctuation but only background colors could be applied. Not sure if it's worth it.

[kortschak]

The reason I think it should be like that is if people are using background to separately mark the function from the parameters, that will bleed into the space. I don't use background, but I do mark the function differently to the parameters.

[kortschak]

Sorry, clobbered your commit. The naming of the space can be changed to suit.

[kortschak]

@deathaxe Thank you for your help and patience with this.