reflect: gccgo+gotip1.6beta1 crashes on multi-line field tags

[zigo101]

What version of Go are you using (go version)?

$ go version
go version go1.16beta1 linux/amd64
$ gccgo --version
gccgo (Debian 8.3.0-6) 8.3.0

Does this issue reproduce with the latest release?

No.

What did you do?

package main

import "fmt"
import "reflect"

type T struct {
	Z bool `optional:"yes" name:"zz
" default:"true"`
}

func main() {
	t := reflect.TypeOf(T{})
	z := t.Field(0).Tag
	fmt.Println(z.Lookup("optional"))
	fmt.Println(z.Lookup("default"))
	fmt.Println(z.Lookup("max"))
}

What did you expect to see?

gccgo will not crash in compiling.

And should z.Lookup("default") return "" false instead?

What did you see instead?

$ go version
go version go1.16beta1 linux/amd64
$ go run a.go
yes true
true true
 false
$ go run -compiler=gccgo a.go
# command-line-arguments
/usr/bin/ld: $WORK/b001/_pkg_.a(_go_.o): in function `main.main..init0':
/tmp/go-build/b001/_gomod_.go:5: undefined reference to `runtime.setmodinfo'
collect2: error: ld returned 1 exit status
$ go version
go version go1.15.5 linux/amd64
$ go run a.go
yes true
true true
 false
$ go run -compiler=gccgo a.go
yes true
true true
 false

[ianlancetaylor]

Closing as a dup of #42916. I don't think this has anything to do with multi-line field tags as such.

[zigo101]

So the workable multi-line field tag workaround is unintended, but they will be kept as such for compatibility?

[ianlancetaylor]

Maybe I'm misunderstanding. Are you saying that if you add or remove a multi-line field tag it changes the behavior on tip?

[zigo101]

I just asked to confirm whether or not the key-value pair default:"true" in the field tags is intended to be valid.

[ianlancetaylor]

The docs for struct tags say that the value string should use Go string literal syntax, so I think that putting a bare newline in a value string does not follow the documentation.

[zigo101]

putting a bare newline in a value string does not follow the documentation.

I understand this. So I'm not surprised that the field Z doesn't have a name key in its tag.
But I'm uncertain whether or not I should be surprised that the field Z has a default key in its tag.

What is the principle difference to make the field Z has a default key in tag but the field W has not?

package main

import "fmt"
import "reflect"

type T struct {
	Z int `optional:"111" name:"22
	       2" default:"333"`
	W int `optional:"111" 
	       name:"222" default:"333"`
}

func main() {
	t := reflect.TypeOf(T{})
	
	z := t.Field(0).Tag
	fmt.Println(z.Lookup("optional")) // 111 true
	fmt.Println(z.Lookup("name"))     //  false
	fmt.Println(z.Lookup("default"))  // 333 true
	
	w := t.Field(1).Tag
	fmt.Println(w.Lookup("optional")) // 111 true
	fmt.Println(w.Lookup("name"))     //  false
	fmt.Println(w.Lookup("default"))  //  false
}

[ianlancetaylor]

The reflect.StructTag.Get method is only documented as handling struct tags that fit the documented format. There is no prediction or guarantee made for struct tags that do not fit the documented format. You can look at the code to see why the two cases behave differently if you like, but there is no promise that those cases will not change in some future release. So while I'm sure your question has an answer, I don't think it's a very interesting one.

[zigo101]

Thanks for confirming this is a unspecified behavior.