Historically gccgo and GoLLVM haven't bother to provide "go tool cover" because they already support -gccgoflags=-pg to get coverage reports.

Historically gccgo and GoLLVM haven't bother to provide "go tool cover" because they already support -gccgoflags=-pg to get coverage reports.

I wouldn't be so sure about that

go test -gccgoflags='-pg' ./...
github.com/openfaas/faas-provider/auth [github.com/openfaas/faas-provider/auth.test]
/usr/local/bin/llvm-goc: error: unrecognized command line option '-pg'

My apologies, I withdraw my statement about GoLLVM.

CC @thanm @cherrymui

As Ian mentioned, "go tool cover" is specific to the GC toolchain.

Correct, gollvm doesn't implement "-pg" at the moment. I would imagine it's doable, I think nobody has bothered to look into it yet.

As Ian mentioned, "go tool cover" is specific to the GC toolchain.

Correct, gollvm doesn't implement "-pg" at the moment. I would imagine it's doable, I think nobody has bothered to look into it yet.

@thanm , could you open a PR issue?

could you open a PR issue?

There are many features not supported by Gollvm; I am not sure what good it would do to create a laundry list of issues enumerating all the things that could be done but are not. Doing this simple clutters up the Go issue tracker as I see it (more productive I think to have these sorts of discussions (we should implement feature ABC instead of XYZ) on a mailing list like go-dev.

It also goes without saying that the main obstacle here is contributor bandwidth. I myself have a very limited amount of time to spend working on Gollvm-- there are many other higher-priority tasks for me at the moment. If we want to add new features, someone has to be willing to devote time to implementing them.

Anyhow we don't need to open another issue, we already have this one.

In general I agree with @thanm: we don't need a list of things to improve in GoLLVM or gccgo. We know lots of things we can do. What we need is not things to do, but people willing to work on them.

Although the gcc and llvm tool chains have support for coverage, the Go cover tool should be completely portable. It should be very easy to get it working for other compilers since it requires no compiler support.

@robpike , would you are interested to contribute into this?

could you open a PR issue?

There are many features not supported by Gollvm; I am not sure what good it would do to create a laundry list of issues enumerating all the things that could be done but are not. Doing this simple clutters up the Go issue tracker as I see it (more productive I think to have these sorts of discussions (we should implement feature ABC instead of XYZ) on a mailing list like go-dev.

It also goes without saying that the main obstacle here is contributor bandwidth. I myself have a very limited amount of time to spend working on Gollvm-- there are many other higher-priority tasks for me at the moment. If we want to add new features, someone has to be willing to devote time to implementing them.

@thanm , I guess we could try to share things via Gophers Slack. I might spend some time on chatting.
Mailing list sounds like a good idea - but we would still require a list of non-yet-supported features, for gollvm.