Thanks for doing this, Alessandro! I will take this, I can see one small change that will fix a bunch of these wrong positions (which are often because of new nodes added for implicit operations like conversions). Then I'll try to hunt down the remaining wrong positions.

@aarzilli I think the "-l" option was not gettiing parsed correctly in the gcflags option, so there was still inlining happening. I changed the line to:

        out, err := exec.Command("go", "build", "-o", tgt, "-gcflags=-N", "-gcflags=-l", path).CombinedOutput()

and got fewer errors, because now there was no inlining.

Then I was able to fix the rest of the errors with the upcoming change (some still show up because of auto-generated functions, which I think is fine).

Change https://golang.org/cl/363835 mentions this issue: cmd/compile: fix position info for implicit nodes due to generics

AFAICT passing multiple -gcflags options like that does a different thing, they don't get concatenated, the second one replaces the first one. You can see it with -x, with -gcflags='-N -l' the call to the compiler is:

/usr/local/go/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath "$WORK/b001=>" -p main -complete -buildid LK_v-5NKMW9Krnt-raXK/LK_v-5NKMW9Krnt-raXK -N -l -c=4 -nolocalimports -importcfg $WORK/b001/importcfg -pack ./test.go $WORK/b001/_gomod_.go

with -gcflags=-N -gcflags=-l it's:

/usr/local/go/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath "$WORK/b001=>" -p main -complete -buildid cdP0z86604nOtUfGIdfU/cdP0z86604nOtUfGIdfU -l -c=4 -nolocalimports -importcfg $WORK/b001/importcfg -pack ./test.go $WORK/b001/_gomod_.go

Enabling optimizations removes some of the instructions that had incorrect line numbers, hence fewer errors.

@aarzilli Yes, thanks, that makes sense now. I thought inlining was still happening, but it was a position problem related to multiple return values. I fixed that issue as well. So, there are no issues, except for auto-generated code (which I think are fine), when running bad.go now.

Thanks!