panic: duplicate field

[philrz]

The following (somewhat contrived) query causes a panic:

$ super -c "SELECT 1 AS x, 2 AS x, 3 AS x_1;"
panic: duplicate field: "x_1"

goroutine 1 [running]:
github.com/brimdata/super.(*Context).MustLookupTypeRecord(...)
	/Users/phil/work/super/context.go:143
github.com/brimdata/super/compiler/semantic.(*translator).emitProjection(0x7f6a3150480, {0x7f6a2f5f440, 0x3, 0x0?}, 0x0, {0x7f6a2f37810, 0x1, 0x1})
	/Users/phil/work/super/compiler/semantic/sql.go:258 +0xac5
github.com/brimdata/super/compiler/semantic.(*translator).sqlSelect(0x7f6a3150480, 0x7f6a3095400, {0x0, 0x0, 0x60?}, {0x0?, 0x5?, 0x1153abe0?}, {0xeff32d0, 0xf329c20})
	/Users/phil/work/super/compiler/semantic/sql.go:106 +0xd93
github.com/brimdata/super/compiler/semantic.(*translator).sqlQueryBody(0x0?, {0xefffea8?, 0x7f6a3095400?}, {0x0?, 0x1?, 0x1?}, {0x0?, 0x7f6a2f60c30?, 0x2?}, {0xeff32d0, ...})
	/Users/phil/work/super/compiler/semantic/sql.go:440 +0x2eb
github.com/brimdata/super/compiler/semantic.(*translator).sqlQueryBody(0x7f6a3150480, {0xefff9f8?, 0x7f6a31676d0}, {0x0?, 0x0?, 0xf2f2a00?}, {0x0, 0x0, 0x0}, {0xeff32d0, ...})
	/Users/phil/work/super/compiler/semantic/sql.go:452 +0xfb5
github.com/brimdata/super/compiler/semantic.(*translator).semOp(0x7f6a3150480, {0xf0004a8?, 0x7f6a2f605d0}, {0x0, 0x0, 0x0}, {0xeff32d0, 0xf329c20})
	/Users/phil/work/super/compiler/semantic/op.go:590 +0x397e
github.com/brimdata/super/compiler/semantic.(*translator).seq(0x7f6a3150480, {0x7f6a2f37700?, 0x7f6a31552b0?, 0x7f6a31503f0?}, {0xeff32d0?, 0xf329c20?})
	/Users/phil/work/super/compiler/semantic/op.go:41 +0x134
github.com/brimdata/super/compiler/semantic.Analyze({0xf009620?, 0x7f6a2f60e10?}, 0x7f6a2f351e0, 0xbb7ac14?, 0x8?)
	/Users/phil/work/super/compiler/semantic/analyzer.go:27 +0x2f7
github.com/brimdata/super/compiler.Analyze(...)
	/Users/phil/work/super/compiler/package.go:23
github.com/brimdata/super/compiler.CompileWithAST(0x7f6a2f60e10, 0xbd104e5?, 0x7f6a3167770?, 0x1, 0xc, {0x0?, 0xeeff3c0?, 0x7f6a3167701?})
	/Users/phil/work/super/compiler/package.go:68 +0x252
github.com/brimdata/super/compiler.(*compiler).NewQuery(0xf0096c8?, 0x7f6a30e8c80?, 0x7f6a339f918?, {0x0?, 0x48?, 0xef02700?}, 0x7f6a339f918?)
	/Users/phil/work/super/compiler/compiler.go:42 +0x45
github.com/brimdata/super/runtime.CompileQuery({0xf0096c8?, 0x7f6a30e8c80?}, 0x7f6a3167720, {0xeff2d80, 0x7f6a2f825a0}, 0x7f6a2f351e0, {0x0, 0x0, 0x0})
	/Users/phil/work/super/runtime/compiler.go:31 +0x10f
github.com/brimdata/super/cmd/super/root.(*Command).Run(0x7f6a2f64800, {0x7f6a2dea710, 0x0, 0x0})
	/Users/phil/work/super/cmd/super/root/command.go:95 +0x5df
github.com/brimdata/super/pkg/charm.path.run({0x7f6a2d9c230, 0x1, 0x1}, {0x7f6a2dea710, 0x0, 0x0?})
	/Users/phil/work/super/pkg/charm/path.go:11 +0x7b
github.com/brimdata/super/pkg/charm.(*Spec).Exec(0xf2a4900, {0x7f6a2dea700, 0x2, 0x2})
	/Users/phil/work/super/pkg/charm/charm.go:74 +0x1fa
main.main()
	/Users/phil/work/super/cmd/super/main.go:40 +0x5b

As does this slightly-less-contrived JOIN query:

$ echo '{id:1, id_1:"pre"}' > c.sup &&
  echo '{id:1}' > d.sup &&
  super -c "FROM 'c.sup' AS a JOIN 'd.sup' AS b ON a.id=b.id SELECT *"

panic: duplicate field: "id_1"

goroutine 1 [running]:
github.com/brimdata/super.(*Context).MustLookupTypeRecord(...)
	/Users/phil/work/super/context.go:143
github.com/brimdata/super/compiler/semantic.(*translator).emitProjection(0x35963ef1e360, {0x35963f040000, 0x3, 0x0?}, 0x0, {0x35963f018a00, 0x3, 0x4})
	/Users/phil/work/super/compiler/semantic/sql.go:258 +0xac5
github.com/brimdata/super/compiler/semantic.(*translator).sqlSelect(0x35963ef1e360, 0x35963ef1c6e0, {0x0, 0x0, 0x60?}, {0x0?, 0x5?, 0xe43e2e8?}, {0xbef72d0, 0xc22dc20})
	/Users/phil/work/super/compiler/semantic/sql.go:106 +0xd93
github.com/brimdata/super/compiler/semantic.(*translator).sqlQueryBody(0x0?, {0xbf03ea8?, 0x35963ef1c6e0?}, {0x0?, 0x1?, 0x1?}, {0x0?, 0x35963f01b110?, 0x2?}, {0xbef72d0, ...})
	/Users/phil/work/super/compiler/semantic/sql.go:440 +0x2eb
github.com/brimdata/super/compiler/semantic.(*translator).sqlQueryBody(0x35963ef1e360, {0xbf039f8?, 0x35963eef9680}, {0x0?, 0x0?, 0xc1f6a00?}, {0x0, 0x0, 0x0}, {0xbef72d0, ...})
	/Users/phil/work/super/compiler/semantic/sql.go:452 +0xfb5
github.com/brimdata/super/compiler/semantic.(*translator).semOp(0x35963ef1e360, {0xbf044a8?, 0x35963f01aab0}, {0x0, 0x0, 0x0}, {0xbef72d0, 0xc22dc20})
	/Users/phil/work/super/compiler/semantic/op.go:590 +0x397e
github.com/brimdata/super/compiler/semantic.(*translator).seq(0x35963ef1e360, {0x35963f013010?, 0x35963ef23930?, 0x35963ef1e2d0?}, {0xbef72d0?, 0xc22dc20?})
	/Users/phil/work/super/compiler/semantic/op.go:41 +0x134
github.com/brimdata/super/compiler/semantic.Analyze({0xbf0d620?, 0x35963f01b2f0?}, 0x35963efc1e60, 0x8a7ec14?, 0x8?)
	/Users/phil/work/super/compiler/semantic/analyzer.go:27 +0x2f7
github.com/brimdata/super/compiler.Analyze(...)
	/Users/phil/work/super/compiler/package.go:23
github.com/brimdata/super/compiler.CompileWithAST(0x35963f01b2f0, 0x8c144e5?, 0x35963eef9720?, 0x1, 0xc, {0x0?, 0xbe033c0?, 0x35963eef9701?})
	/Users/phil/work/super/compiler/package.go:68 +0x252
github.com/brimdata/super/compiler.(*compiler).NewQuery(0xbf0d6c8?, 0x35963eeaad70?, 0x35963f2af918?, {0x0?, 0x48?, 0xbe06700?}, 0x35963f2af918?)
	/Users/phil/work/super/compiler/compiler.go:42 +0x45
github.com/brimdata/super/runtime.CompileQuery({0xbf0d6c8?, 0x35963eeaad70?}, 0x35963eef96d0, {0xbef6d80, 0x35963ed121c0}, 0x35963efc1e60, {0x0, 0x0, 0x0})
	/Users/phil/work/super/runtime/compiler.go:31 +0x10f
github.com/brimdata/super/cmd/super/root.(*Command).Run(0x35963efe2200, {0x35963ee2c6e0, 0x0, 0x0})
	/Users/phil/work/super/cmd/super/root/command.go:95 +0x5df
github.com/brimdata/super/pkg/charm.path.run({0x35963f282170, 0x1, 0x1}, {0x35963ee2c6e0, 0x0, 0x0?})
	/Users/phil/work/super/pkg/charm/path.go:11 +0x7b
github.com/brimdata/super/pkg/charm.(*Spec).Exec(0xc1a8900, {0x35963ee2c6d0, 0x2, 0x2})
	/Users/phil/work/super/pkg/charm/charm.go:74 +0x1fa
main.main()
	/Users/phil/work/super/cmd/super/main.go:40 +0x5b

Details

Repro is with super commit 2e0c0b2.

As evident from the repros, the problem comes down to the collision between of the _1 alternate field name that's cooked up by SuperDB and the potential presence of genuine incoming user data that happens to coincidentally have a trailing _1. While perhaps unlikely, it seems this is not impossible, and something other than a panic would likely be an improvement, in the spirit of what was similarly fixed in #5870.