On Fri, Jan 31, 2020 at 12:19 AM Craig Rodrigues <crodr...@gmail.com> wrote: > > On Thursday, January 30, 2020 at 11:03:04 PM UTC-8, Craig Rodrigues wrote: >> >> >> >> On Thursday, January 30, 2020 at 10:06:36 PM UTC-8, Ian Lance Taylor wrote: >>> >>> On Thu, Jan 30, 2020 at 9:43 PM Craig Rodrigues <crod...@gmail.com> wrote: >>> > I see here that this might be related: >>> > https://golang.org/doc/go1.13#testing >>> > >>> > Testing flags are now registered in the new Init function, >>> > which is invoked by the generated main function for the test. >>> > As a result, testing flags are now only registered when running >>> > a test binary, and packages that call flag.Parse during package >>> > initialization may cause tests to fail. >>> > >>> > But I'm not sure how to move forward to get back the behavior from go >>> > 1.12. >>> >>> That could well be the problem. If so, the solution is to not call >>> flag.Parse from an init function. >> >> >> >> Ah OK! >> >> So my_test.go , and every test file in my codebase has: >> >> func init() { >> ParseFlags() >> } >> >> which calls flag.Parse for a bunch of framework-specific test flags. >> >> How should I restructure this so that I get the "-test.XXX" flags generated >> in the binary, >> like I did with go 1.12? > > > > This change in go test seems due to this: > > https://github.com/golang/go/issues/21051 > https://go-review.googlesource.com/c/go/+/173722/ > > > so for my function: > > func init() { > ParseFlags() > } > > I went in the ParseFlags() function and removed a call to flag.Parse() as > suggested by Ian (thanks for that suggestion!). > > That seemed to fix things for me. > > Will this be guaranteed to work in future go versions, or could this behavior > change if something > else changes in the internals of go test?
This will work in future Go versions. Calling flag.Parse in an init function never worked reliably, unless you took special care. Flags are themselves often defined in init functions, so calling flag.Parse in an init function will see the flags that were defined before the point of the call but not the flags defined after the point of the call. I guess it was working for you, but small changes in your code could have caused it to stop working. We didn't document that calling flags.Parse in an init function didn't work reliably because we didn't realize that anybody would ever do it. The documentation always just said "After all flags are defined, call flag.Parse", and "Must be called after all flags are defined and before flags are accessed by the program" without spelling out that if you call it in an init function you won't necessarily be calling it after all flags are defined. The change to the testing package changed exactly when the testing flags are defined with respect to init functions, and it caused many cases of calling flag.Parse from an init function to break. But those cases were already fragile and could have been broken in other ways also. If you don't call flag.Parse from an init function you will be following the documentation, and that will continue to work. Sorry for the trouble. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXPkwXFXfdbkKvGeeiOWSWCet4jYjCR02ofq2mo3KKuFw%40mail.gmail.com.
