I'm not sure I understand this report.

The second paste has the usual too many errors line, which means that only a few errors were reported, is that right? Wasn't the first one invalid recursive type string? Or was that error line missing? Or it was there and you didn't past it? Also, there were no line numbers?

Can you post a reproducer that actually triggers the behaviour that you found "harder to debug"?

The full output was:

▶ go build
# github.com/gohugoio/hugo/hugolib
hugolib/menu.go:45: invalid map key type string
hugolib/multilingual.go:34: invalid map key type string
hugolib/page.go:97: invalid map key type string
hugolib/shortcode.go:184: invalid map key type scKey
hugolib/shortcode.go:188: invalid map key type scKey
hugolib/shortcode.go:193: invalid map key type string
hugolib/shortcode.go:196: invalid map key type string
hugolib/shortcode.go:199: invalid map key type string
hugolib/taxonomy.go:23: invalid map key type string
hugolib/taxonomy.go:33: invalid map key type string
hugolib/taxonomy.go:23: too many errors

I can update my original description to make it clearer if you want (I chose not to, as that would make your reply look out of place).

I can add to this that if this was a type definition deep down in some vendored lib, I would probably never have found it ...

Thanks for clarifying. It's clear that the current output is not ideal because the fact that the invalid recursive type string error -cause of all the other errors- wasn't printed makes really hard to debug this kind of issue.

Here's a one-file reproducer:

package main

type string string

type a struct {
	m map[string]int
}

type b1 map[string]int
type b2 map[string]int
type b3 map[string]int
type b4 map[string]int
type b5 map[string]int
type b6 map[string]int
type b7 map[string]int
type b8 map[string]int
type b9 map[string]int

Output:

tmp/sandbox809932791/main.go:6: invalid map key type string
tmp/sandbox809932791/main.go:9: invalid map key type string
tmp/sandbox809932791/main.go:10: invalid map key type string
tmp/sandbox809932791/main.go:11: invalid map key type string
tmp/sandbox809932791/main.go:12: invalid map key type string
tmp/sandbox809932791/main.go:13: invalid map key type string
tmp/sandbox809932791/main.go:14: invalid map key type string
tmp/sandbox809932791/main.go:15: invalid map key type string
tmp/sandbox809932791/main.go:16: invalid map key type string
tmp/sandbox809932791/main.go:17: invalid map key type string
tmp/sandbox809932791/main.go:17: too many errors

If you comment one of the type bX line, you'll also get (in first position), the error that points to the actual culprit:

tmp/sandbox056532838/main.go:3: invalid recursive type string

Choosing which errors to print (or to abort in specific places) is not easy, I'm not sure if it's even possible to choose a general policy that will work well in every case.

Better repro case:

r$ go tool compile /tmp/x.go
/tmp/x.go:4:2: invalid recursive type T
/tmp/x.go:6:5: invalid map key type T
r$ cat /tmp/x.go
package main

type (
	T T
	a      struct {
		m map[T]int
	}
)
r$ 

There's no need to tell me T is an invalid map key after telling me it's an invalid anything.

Likely related, this variation leads to a compiler stack overflow:

package p

type (
	T struct { T }
	_ map[T]int
)

(which happens to be #21657)

Change https://golang.org/cl/75310 mentions this issue: cmd/compile: avoid spurious errors for invalid map key types