Skip to content

/ go

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: move GOEXPERIMENT knob from make.bash to cmd/go #42681

Open
mdempsky opened this issue Nov 17, 2020 · 6 comments
Open

proposal: move GOEXPERIMENT knob from make.bash to cmd/go #42681

mdempsky opened this issue Nov 17, 2020 · 6 comments
Labels
Proposal
Projects
Proposals
Milestone
Proposal

Comments

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Nov 17, 2020

GOEXPERIMENT currently allows trying out a handful of different experimental toolchain features, none of which need to be decided at make.bash time. We can just make the rest of the toolchain GOEXPERIMENT-aware. (If you really want the toolchain itself to be built with an experiment enabled, "GOEXPERIMENT=foo go install -a cmd" would work.)
@mdempsky mdempsky added the Proposal label Nov 17, 2020
@gopherbot gopherbot added this to the Proposal milestone Nov 17, 2020
@mdempsky mdempsky mentioned this issue Nov 17, 2020
Open
@bcmills
Copy link
Member

@bcmills bcmills commented Nov 18, 2020

How many of the GOEXPERIMENT values could instead be -gcflags or build constraints, both of which cmd/go already understands?

I'd rather we reduce than add to the number of ways to vary the build configuration.
@mdempsky
Copy link
Member Author

@mdempsky mdempsky commented Nov 18, 2020 •
edited

I don't feel strongly about whether GOEXPERIMENT should be the knob used by cmd/compile and other tools. I think it would be a simpler incremental step to continue using that, but I'm fine switching to normal flags too.

I do think cmd/go should probably be in charge of orchestrating everything still somehow. I've seen users too frequently use -gcflags=foo instead of -gcflags=all=foo; use just -gcflags without realizing they need to pass linker flags too; etc.
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 18, 2020

Change https://golang.org/cl/271217 mentions this issue: cmd/compile: fix panic in field tracking logic
gopherbot pushed a commit that referenced this issue Nov 18, 2020
@mdempsky
cmd/compile: fix panic in field tracking logic
5b0ec1a 
Within the frontend, we generally don't guarantee uniqueness of
anonymous types. For example, each struct type literal gets
represented by its own types.Type instance.

However, the field tracking code was using the struct type as a map
key. This broke in golang.org/cl/256457, because that CL started
changing the inlined parameter variables from using the types.Type of
the declared parameter to that of the call site argument. These are
always identical types (e.g., types.Identical would report true), but
they can be different pointer values, causing the map lookup to fail.

The easiest fix is to simply get rid of the map and instead use
Node.Opt for tracking the types.Field. To mitigate against more latent
field tracking failures (e.g., if any other code were to start trying
to use Opt on ODOT/ODOTPTR fields), we store this field
unconditionally. I also expect having the types.Field will be useful
to other frontend code in the future.

Finally, to make it easier to test field tracking without having to
run make.bash with GOEXPERIMENT=fieldtrack, this commit adds a
-d=fieldtrack flag as an alternative way to enable field tracking
within the compiler. See also #42681.

Fixes #42686.

Change-Id: I6923d206d5e2cab1e6798cba36cae96c1eeaea55
Reviewed-on: https://go-review.googlesource.com/c/go/+/271217
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
@bcmills
Copy link
Member

@bcmills bcmills commented Nov 19, 2020 •
edited

I think this kind of interacts with the various proposals for build configurations (#39005, #42343, and perhaps others; CC @mvdan @dominikh @jayconrod @matloob).

In particular, you can think of a GOEXPERIMENT value as essentially just a predefined shorthand for a set of build flags. If we add some mechanism for users to define their own shorthand for sets of build flags, we should try to get GOEXPERIMENT to converge (or at least harmonize) with that.
@ianlancetaylor ianlancetaylor mentioned this issue Nov 19, 2020
Closed
@gopherbot
Copy link

@gopherbot gopherbot commented Dec 24, 2020

Change https://golang.org/cl/280113 mentions this issue: [dev.regabi] cmd: move GOEXPERIMENT knob from make.bash to cmd/go
@mdempsky
Copy link
Member Author

@mdempsky mdempsky commented Dec 24, 2020

CL 280113 demonstrates what I had in mind for this. I've tested and confirmed it works for fieldtrack. I don't see any reason it shouldn't work for others.

I think there are some rough edges still (e.g., I suspect GOENV doesn't work to set GOEXPERIMENT, and setting GOEXPERIMENT should probably update the package suffix), but I'll clean those up if this is a worthwhile direction to pursue. I think it is.

/cc @rsc @aclements @cherrymui @thanm
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Jan 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Proposal
Projects
Proposals
Incoming
Milestone
Proposal
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
@mdempsky @bcmills @gopherbot