Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

More details:

I guess I'm using the analyzer in a way it wasn't intended. And in fact the problem is deeper than the race condition around the flags. But I hope you can help me find a solution, thanks! 🙏

https://github.com/Antonboom/go-analysis-printf-race is going outside of what is supported. I think gophers.slack.com is a better venue for this question. #tools and #static-analysis are both good.

P.S. Technically, the analyzers are started one after another (but in a nested form), so it’s not clear what race detector doesn’t like

This analyzer has facts so singlechecker.Main runs the analyzer on transitive imports too. Any package with realistic imports is not totally ordered and creates actions that can run in parallel. Example: package a transitively imports b and c where b and c do not transitively import each other. Then passes (go-analysis-printf-race/analyzer.Analyzer, b) and (go-analysis-printf-race/analyzer.Analyzer, c) can be scheduled in parallel. anlzr.Flags.Set is just setting a global (and setting it too late) within parallel Run cases. Hence the race.

@timothy-king thank you for quick reply

I made an issue because wanted to highlight some area for improvements.

And now I try to understand – I need to find a workaround (if it is technically possible at all) on my own or I can hope for some changes in printf / Run.

I think the feature like "run analyzer inside analyzer" is useful and see two ways:

1. Implement ad-hoc patch for my case (e.g. make stringSet is thread safe). I can do it.
2. Open proposal for "analyzer inside analyzer" feature.

?

Open proposal for "analyzer inside analyzer" feature.

You can file this proposal, but keep in mind that to be accepted it needs to (1) work with unitchecker (e.g. a process per package) (2) communicate facts correctly to its driver, and (3) not be redundant with communicating via Results.

My recommendation is to take a step back think about the graph of Passes and how a driver of the analysis framework is required to execute these. See
https://pkg.go.dev/golang.org/x/tools/go/analysis#hdr-Pass and
https://pkg.go.dev/golang.org/x/tools/go/analysis#hdr-Modular_analysis_with_Facts .

IMO what you are hoping for is a dependency in this graph that is a leaf and all passes of an analyzer have as a dependency. Setting flags is the supported path for such leaves at the moment. It would be nice to have better alternatives for this and proposals for this are welcomed.

Implement ad-hoc patch for my case (e.g. make stringSet is thread safe). I can do it.

You can, but setting a global immediately before each call is kinda hacky. A moderate improvement is to do this once func init() { if err := anlzr.Flags.Set("funcs", "logger.Printf,logger.Fprintf"); err != nil { panic(err) } }. Also hacky. It is not terribly compatible with another user of printf.Analyzer nor adjusting the flags via go vet -vettool=.... Maybe a few other things.

You can also file a proposal to add a function that returns a new *Analyzer object for printf based on a given configuration. That will be easier to get correct.

Change https://go.dev/cl/580555 mentions this issue: analysis/passes/printf: introduce analyzer constructor

You can also file a proposal to add a function that returns a new *Analyzer object for printf based on a given configuration. That will be easier to get correct.

This is exactly what I do in my analyzers but completely forgot about it, affected by singleton nature of std passes 🤦
PR raised. Thank you!