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
cmd/compile: Biobuf duplication #10652
Comments
I'm all for deleting code, using bufio.Buffer everywhere sounds great. |
That's fair, but please consider at least applying https://go-review.googlesource.com/#/c/9529/ |
CL https://golang.org/cl/9660 mentions this issue. |
Update #10652 This proposal deletes cmd/internal/ld.Biobuf and replaces all uses with cmd/internal/obj.Biobuf. As cmd/internal/ld already imported cmd/internal/obj there are no additional dependencies created. Notes: - ld.Boffset included more checks, so it was merged into obj.Boffset - obj.Bflush was removed in 8d16253, so replaced all calls to ld.Bflush, with obj.Biobuf.Flush. - Almost all of this change was prepared with sed. Change-Id: I814854d52f5729a5a40c523c8188e465246b88da Reviewed-on: https://go-review.googlesource.com/9660 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Dave Cheney <dave@cheney.net>
CL https://golang.org/cl/13886 mentions this issue. |
I think the original issue was resolved if we are just talking of the copies of Biobuf.
However, in @davecheney's CL https://go-review.googlesource.com/#/c/21720 he noted at 8f2edf1#diff-c6708995b52ed026c5e6632418f7a3b6R247 that the logic of bio.Writer was duplicated in a small internal struct. Perhaps a new issue to refactor/replace that unexported code can then be opened since the original duplication issue was solved? Any thoughts? |
I think when gri deletes the old importer code from the compiler in 1.8 On Fri, Aug 5, 2016 at 6:33 PM, Emmanuel T Odeke notifications@github.com
|
This no longer seems to be the case:
|
There are two copes of
Biobuf
in the compiler,cmd/internal/obj/util.go
andcmd/internal/ld/util.go
. Both are in various stages of decomposition, for example 05d5316 was applied to the latter, but not the former. The former has sort of had 05d5316 applied accidentally, and nowBungetc
is inconsistent, some methods check the unget buffer, others do not.bufio.Buffer
, then there should be at most one in the compiler.bufio.Buffer
directly everywhere.@rsc @robpike thoughts ?
The text was updated successfully, but these errors were encountered: