internal/cfg: GOROOT_FINAL isn't included in KnownEnv, hard to tell if that's a bug or intentional

[dmitshur]

I've noticed the current cfg.KnownEnv list does not include the GOROOT_FINAL environment variable.

We know from #39385 that GOROOT_FINAL has some (albeit indirect) effect on the behavior of the Go command (fortunately, GOROOT_FINAL_OLD no longer does).

Should GOROOT_FINAL be included in cfg.KnownEnv, or is it intentional that it's not listed?

The documentation for KnownEnv is somewhat brief:

// KnownEnv is a list of environment variables that affect the operation
// of the Go command.

It'd be nice to clarify if it's meant to be an exhaustive list or not, and whether some env vars should be intentionally left out or not.

/cc @bcmills @matloob @jayconrod

[dmitshur]

GOROOT_FINAL has some (albeit indirect) effect

It might be indirect enough to be considered no effect. Perhaps the scope of these env vars are vars that can modify cmd/go behavior only after the Go tree has been installed, and cmd/go tests are out of scope. I wasn't sure from the documentation, which is in large part what this issue is about.

[bcmills]

Hmm, that's an interesting question. The main purpose of cfg.KnownEnv is to control which variables may be stored (and read) from the go/env configuration file, but today we do not read GOROOT_FINAL from that file:

go/src/cmd/go/internal/cfg/cfg.go

Lines 336 to 344 in daf70d6

	func findGOROOT_FINAL() string {
	// $GOROOT_FINAL is only for use during make.bash
	// so it is not settable using go/env, so we use os.Getenv here.
	def := GOROOT
	if env := os.Getenv("GOROOT_FINAL"); env != "" {
	def = filepath.Clean(env)
	}
	return def
	}

On the other hand, it really does affect the behavior of cmd/go for all binaries that depend on std, not just during make.bash.

[bcmills]

Note that there are a few other environment variables that affect compiler behavior that are also not supported in go/env or tracked as test inputs:

• GO_GCFLAGS (test: doesn't use GO_GCFLAGS for tests #18222)
• GOSSAFUNC, GOSSAHASH (cmd/compile: ssa debug does not regenerate/update ssa.html #31290; see especially cmd/compile: ssa debug does not regenerate/update ssa.html #31290 (comment))
• possiblyGOCLOBBERDEADHASH, and GO_SSA_PHI_LOC_CUTOFF (but I couldn't find any remaining sites in the code that actually consume these variables, so maybe they're gone now).
• GSHS_LOGFILE:
  

  go/src/cmd/compile/internal/ssa/func.go

  Line 734 in 7e71c9c

  if tmpfile := os.Getenv("GSHS_LOGFILE"); tmpfile != "" {

  
  

  go/src/cmd/go/internal/work/exec.go

  Lines 286 to 292 in 567556d

  	if os.Getenv("GSHS_LOGFILE") != "" {
  	// Clumsy hack. Compiler writes to this log file,
  	// so do not allow use of cache at all.
  	// We will still write to the cache but it will be
  	// essentially unfindable.
  	fmt.Fprintf(h, "nocache %d\n", time.Now().UnixNano())
  	}

However, GOROOT_FINAL is somewhat different from those in that it is interpreted directly by cmd/go.

[iwdgo]

GOROOT_FINAL has been removed following #62047.
Nothing seems left to do to resolve this issue.

[qiulaidongfeng]

@dmitshur I noticed this issue while searching on github, now that GOROOT_FINAL has been removed, please close this issue.

[dmitshur]

It’s true that GOROOT_FINAL is removed in Go 1.23, so it’s no longer relevant. As #39819 (comment) points out, there are more env vars that might need consideration. But perhaps that can be deferred until there’s a concrete need. Closing for now.