Skip to content
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

Closed
davecheney opened this issue May 1, 2015 · 7 comments
Closed

cmd/compile: Biobuf duplication #10652

davecheney opened this issue May 1, 2015 · 7 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@davecheney
Copy link
Contributor

There are two copes of Biobuf in the compiler, cmd/internal/obj/util.go and cmd/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 now Bungetc is inconsistent, some methods check the unget buffer, others do not.

  • If there must be a wrapper around bufio.Buffer, then there should be at most one in the compiler.
  • Preferably we should be using bufio.Buffer directly everywhere.

@rsc @robpike thoughts ?

@davecheney davecheney self-assigned this May 1, 2015
@davecheney davecheney added this to the Go1.5 milestone May 1, 2015
@randall77
Copy link
Contributor

I'm all for deleting code, using bufio.Buffer everywhere sounds great.
For 1.5, however, it is a bit late. That's a lot of lines to change after the freeze.

@davecheney davecheney modified the milestones: Go1.5Maybe, Go1.5 May 1, 2015
@davecheney
Copy link
Contributor Author

That's fair, but please consider at least applying https://go-review.googlesource.com/#/c/9529/

@gopherbot
Copy link

CL https://golang.org/cl/9660 mentions this issue.

davecheney added a commit that referenced this issue May 4, 2015
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>
@davecheney davecheney modified the milestones: Go1.6, Go1.5Maybe May 7, 2015
@rsc rsc changed the title cmd/gc: Biobuf duplication cmd/compile: Biobuf duplication Jun 8, 2015
@gopherbot
Copy link

CL https://golang.org/cl/13886 mentions this issue.

@mdempsky mdempsky modified the milestones: Go1.7, Go1.6 Dec 8, 2015
@rsc rsc modified the milestones: Go1.8, Go1.7 May 17, 2016
@odeke-em
Copy link
Member

odeke-em commented Aug 5, 2016

I think the original issue was resolved if we are just talking of the copies of Biobuf.
After:

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?

@davecheney
Copy link
Contributor Author

I think when gri deletes the old importer code from the compiler in 1.8
this should expose a few more places where bio is not used and will
probably seal its fate.

On Fri, Aug 5, 2016 at 6:33 PM, Emmanuel T Odeke notifications@github.com
wrote:

I think the original issue was resolved if we are just talking of the
copies of Biobuf.
After:

However, in @davecheney https://github.com/davecheney's CL
https://go-review.googlesource.com/#/c/21720 he noted at 8f2edf1#diff-
c6708995b52ed026c5e6632418f7a3b6R247
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?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10652 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA96EG36LQHrx837d45Elx0uv00xkks5qcvVUgaJpZM4ENOEP
.

@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 10, 2016
@rsc rsc modified the milestones: Go1.9Early, Go1.8 Oct 21, 2016
@bradfitz
Copy link
Contributor

bradfitz commented May 3, 2017

This no longer seems to be the case:

$ git grep -i Biobuf
cmd/link/internal/ld/ldpe.go:// TODO(brainman): maybe just add ReadAt method to bio.Reader instead of creating peBiobuf
cmd/link/internal/ld/ldpe.go:// peBiobuf makes bio.Reader look like io.ReaderAt.
cmd/link/internal/ld/ldpe.go:type peBiobuf bio.Reader
cmd/link/internal/ld/ldpe.go:func (f *peBiobuf) ReadAt(p []byte, off int64) (int, error) {
cmd/link/internal/ld/ldpe.go:   sr := io.NewSectionReader((*peBiobuf)(input), input.Offset(), 1<<63-1)
cmd/vendor/golang.org/x/arch/x86/x86asm/testdata/libmach8db.c:  Biobuf bstdout;

@bradfitz bradfitz closed this as completed May 3, 2017
@golang golang locked and limited conversation to collaborators May 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

8 participants