Pretty sure this is because you're missing -covermode=atomic. If you race under the race detector you'd probably see races right now too.

See cmd/go docs:

-covermode set,count,atomic
    Set the mode for coverage analysis for the package[s]
    being tested. The default is "set" unless -race is enabled,
    in which case it is "atomic".
    The values:
	set: bool: does this statement run?
	count: int: how many times does this statement run?
	atomic: int: count, but correct in multithreaded tests;
		significantly more expensive.
    Sets -cover.

@bradfitz this is not true. The test above has been done using -covermode=atomic, it doesn't fix the problem. I tripple checked that one. Look, I even mentioned it in the OP.

Sorry, missed that.

Do you see races, though?

This looks like cmd/cover is either interpreting or displaying the coverage profile in incorrect way.

In the same example, if you use -func mode, it says 100% coverage, which is what we expect. But -html mode is displaying the same incorrectly.

$ go tool cover -func=cover.out
test/19845-cover-parallel/p.go:3: someFunction  100.0%
total:          (statements)  100.0%

$ go tool cover -html=cover.out
... shows wrong coverage in browser ...

Looking into why -html shows wrong lines.

@SmaugTheGreat : When you say it's shown as not covered, do you mean it's shown in red color? Or grey?

In my local run, line return 1 is shown in grey. But that means low-coverage. Not covered lines are shown in red. (It's a heat map apparently; gradually going from grey to green).

@Dhananjay92 It's shown in red color and the cover.out file is also listing the lines as not covered (not just the HTML representation)

I just tested it on my Windows machine at home with the same result (OP is Mac OS X). Here's a screen-shot with all the relevant data: http://imgur.com/vyjuQkK

I can reproduce this both on go1.8 and on tip on a Linux system. Coverage is 66% and html shows the first return line in red (= no coverage).

Thanks. I can also repro 66.7% coverage now. (Silly me; Earlier, I had commented t.Parallel() and forgot to uncomment that! 😅 )

Looking closely at the TestSomeFunction(), it calls someFunction() both times with false (last value in list): https://play.golang.org/p/xUrtBXiSOP

If you copy v in the loop (i.e before passing to concurrent code), problem will go away.

func TestSomeFunction(t *testing.T) {
  someList := []bool {
    true, false,
  }

  for _, v := range someList {
    v2 := v
    t.Run("testx", func(t *testing.T) {
      t.Parallel()
      someFunction(v2)
    })
  }
}

Ah! This is also noted in the testing package documentation:

https://golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks

func TestGroupedParallel(t *testing.T) {
    for _, tc := range tests {
        tc := tc // capture range variable
        t.Run(tc.Name, func(t *testing.T) {
            t.Parallel()
            ...
        })
    }
}

Looks like this is working as intended; the error is in the code.

Indeed.