-
Notifications
You must be signed in to change notification settings - Fork 17.4k
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
proposal: debug/bisect: publish x/tools/internal/bisect #67140
Comments
Alternatively, we keep most of the implementation in |
Thanks for pointing that out. Changed the API for the public package to use io. |
This proposal has been added to the active column of the proposals project |
I’m having a hard time understanding what this does, or how the api methods are meant to be used. Comments on the api methods would be helpful for me. |
Apologies for not linking to it at the start, but the docs for these functions are at https://pkg.go.dev/golang.org/x/tools/internal/bisect. |
I added to the top comment:
|
Thanks, I loved the blog post! Looking for ways to use this at work… |
Have all remaining concerns about this proposal been addressed? The proposal details are in #67140 (comment). |
I need to write the full package docs and post them here, along with some examples. Some things are still not clear. |
The Matcher API makes sense to me, but I find the Marker part of the API pretty confusing. Partly this is a documentation issue (the Marker doc comment as written assumes a lot of context). Partly though I think this requires the user of this API to hook up the parts just right, and things can go wrong if they don't. Specifically:
To me, this suggests that there could be a single method of Matcher that reports that we're making a decision based on this marker and returns what the decision was. That would reduce this example:
to something like
I'm not sure how much flexibility is needed in the reporting. The existence of Minor API commentsSome of these might be obviated if we switch to an API like I suggest above, but I wanted to get them on the record in case they remain relevant.
|
golang.org/x/tools/cmd/bisect is incredibly useful for binary-searching over potential bug locations when a compiler or library change causes a problem. There is a small package that handles the protocol of speaking to the bisect tool, and we have two copies of it: std's internal/bisect (for the compiler and runtime) and also golang.org/x/tools/internal/bisect (for x/tools/cmd/bisect).
We have been using bisect successfully long enough that I feel pretty confident in the API. I propose we publish the package as the standard library package debug/bisect. This will let the compiler and runtime both use it, it will let us drop down to having just one copy of the code, and it will also make the logic available to other programs that want to be bisect-debuggable. In particular, packages beyond the standard library could use it to provide bisectable implementation changes when they make compatible-but-possibly-breaking changes.
The full API is:
For doc comments, see https://pkg.go.dev/golang.org/x/tools/internal/bisect.
For more background, see https://research.swtch.com/bisect.
The text was updated successfully, but these errors were encountered: