This one also doesn't seem to have gone through the proposal process. The issue discussing it is #45104.

Indeed. @griesemer and I did discuss making a proposal at the time, and thought it wasn't warranted. If you or anyone feels differently, I don't mind unexporting the API and waiting for 1.18.

Agreed. This is a just an additional mode, and nothing is expected to break if the mode is ignored.

Sure, I don't expect this to be a breaking change or anything, but normally new API goes through the proposal process.

If this is needed for generics then I think it is covered by that proposal, but that's not obvious to me in this case.

This is not directly needed for generics. As a side-effect of the refactoring I was doing anyway, this optimization, which is desirable for some users, became trivial.

We can unexport this mode value and make a proposal for 1.18. Users can experiment with it in 1.17 by copying the mode value into their project.

It's OK to make it a proposal for 1.17 if you like. I don't think it would take long to approve. Thanks.

Thanks, I've filed #46485 for the proposal. If the discussion there is one-sided we can perhaps get it in for 1.17, but I don't want to rush it.

For now I'll un-export the new mode to close this release blocker.

Change https://golang.org/cl/323909 mentions this issue: go/parser: un-export the SkipObjectResolution mode pending discussion

I discussed this issue with @golang/release today, and consensus was that it can be marked okay-after-beta-1. Reverting the mode is trivial and safe if #46485 is not approved. Leaving the mode in the release for now allows users to more easily experiment with it.

Depending on the outcome of the proposal, I will either document or revert this mode in ~2 weeks.

Change https://golang.org/cl/329009 mentions this issue: doc/go1.17: document go/parser.SkipObjectResolution