cmd/protoc-gen-go: don't chain public imports

Consider the case:

	a.proto publicly imports b.proto
	b.proto publicly imports c.proto

Should a.pb.go include symbols defined in c.pb.go?

Historically, it has not. As of #155677, it does. Regardless of which behavior
is preferable, #155677 produces broken code in some common situations: If
a.proto also publicly imports c.proto, we now generate two copies of the
forwarding decls for that file.

Restore the pre-#155677 behavior to avoid this breakage.

Change-Id: I283600b3be19eac2c3b3c14233bb69fa64661581
Reviewed-on: https://go-review.googlesource.com/c/156348
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2 files changed
tree: d794a9bdc55de77d619f79ae5d610654ee34d4ed
  1. cmd/
  2. encoding/
  3. internal/
  4. proto/
  5. protogen/
  6. reflect/
  7. runtime/
  8. types/
  9. .gitignore
  10. .travis.yml
  11. AUTHORS
  12. CONTRIBUTING.md
  13. CONTRIBUTORS
  14. go.mod
  15. go.sum
  16. LICENSE
  17. PATENTS
  18. README.md
  19. regenerate.bash
  20. test.bash
README.md

Next Generation Go Protocol Buffers

WARNING: This repository is in active development. There are no guarantees about API stability. Breaking changes will occur until a stable release is made and announced.

This repository is for the development of the next major Go implementation of protocol buffers. This library makes breaking API changes relative to the existing Go protobuf library. Of particular note, this API aims to make protobuf reflection a first-class feature of the API and implements the protobuf ecosystem in terms of reflection.

Design Documents

List of relevant design documents:

Contributing

We appreciate community contributions. See CONTRIBUTING.md.

Reporting Issues

Issues regarding the new API can be filed at github.com/golang/protobuf. Please use a APIv2: prefix in the title to make it clear that the issue is regarding the new API work.