Skip to content
Permalink
Branch: master
Commits on Aug 8, 2019
  1. all: rename tag and flags for legacy support

    dsnet committed Aug 8, 2019
    Rename build tag "proto1_legacy" -> "protolegacy"
    to be consistent with the "protoreflect" tag.
    
    Rename flag constant "Proto1Legacy" -> "ProtoLegacy" since
    it covers more than simply proto1 legacy features.
    For example, it covers alpha-features of proto3 that
    were eventually removed from the final proto3 release.
    
    Change-Id: I0f4fcbadd4b5a61c87645e2e5be11d187e59157c
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189345
    Reviewed-by: Damien Neil <dneil@google.com>
  2. test.bash: refactor command execution logic

    dsnet committed Aug 8, 2019
    Refactor the command execution logic to be more configurable.
    
    Change-Id: I6d21f6c3f38691a8ffc992a170ff221c8a06f990
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189341
    Reviewed-by: Damien Neil <dneil@google.com>
Commits on Aug 7, 2019
  1. runtime/protoimpl, cmd/protoc-gen-go: support release versioning

    dsnet committed Jul 10, 2019
    In order for protoc-gen-go to output the current version,
    it needs to know what version it is currently running as.
    However, we cannot rely on the git tags since the tags are not
    made until *after* the commit has been submitted.
    Instead, we manually encode the version into the code and
    make sure that git tags match up with the version in the code.
    
    The version.go file in runtime/protoimpl contains instructions
    for how to make a release. Essentially:
    * Every non-release commit has a version string with "devel" in it.
    * Every release commit must not have "devel" in it and must be unique.
    * The "release process" involves submitting two CLs.
    The first CL creates a version string without "devel",
    which is the commit that a git tag will actually reference.
    The second CL follows immediately and re-introduces "devel"
    into the version string.
    
    The following example shows a possible sequence of VersionStrings
    for git commits in time-ascending order:
    	v1.19.0-devel      (this CL)
    	v1.19.0-devel
    	v1.19.0-devel
    	v1.19.0-devel
    	v1.20.0-rc.1       <- tagged
    	v1.20.0-rc.1.devel
    	v1.20.0-rc.1.devel
    	v1.20.0-rc.1.devel
    	v1.20.0-rc.2       <- tagged
    	v1.20.0-rc.2.devel
    	v1.20.0            <- tagged (future public release)
    	v1.20.0-devel
    	v1.20.0-devel
    	v1.20.0-devel
    	v1.20.0-devel
    	v1.20.1            <- tagged
    	v1.20.1-devel
    	v1.20.1-devel
    	v1.21.0            <- tagged
    	v1.21.0-devel
    
    Note that we start today with v1.19.0-devel, which means that our initial
    release will be v1.20.0. This number was intentionally chosen since
    1) the number 20 has some correlation to the fact that we keep calling
    the new implementation the "v2" implementation, and
    2) the set of tagged versions for github.com/golang/protobuf
    and google.golang.org/protobuf are unlikely to ever overlap.
    This way, the version of protoc-gen-go is never ambiguous which module
    it was built from.
    
    Now that we have version information, we add support for generating .pb.go
    files with the version information recorded. However, we do not emit
    these for .pb.go files in our own repository since they are always guaranteed
    to be at the right version (enforced by integration_test.go).
    
    Updates golang/protobuf#524
    
    Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117
    Reviewed-by: Damien Neil <dneil@google.com>
  2. cmd/protoc-gen-go: improve generation of comments

    dsnet committed Aug 6, 2019
    The following improvements were made:
    * All standalone comments above the "syntax" marker are preserved
    similar to Java and some other generators.
    * All standalone comments above the "package" marker are preserved
    to be consistent with our former behavior.
    * Leading comments are now generated for enums and extension fields.
    * Single-line trailing comments are now generated for
    enum values, message fields, and extension fields.
    * The leading comments for each field that is part of a oneof are now
    generated with the wrapper types rather than being shoved into the
    comment for the oneof itself in an unreadable way.
    * The deprecation marker is always generated as being above the declaration
    rather than sometimes being an inlined comment.
    * The deprecation marker is now properly generated for weak field setters.
    
    Updates golang/protobuf#666
    
    Change-Id: I7fd832dd4f86d15bfff70d7c22c6ba4934c05fcf
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189238
    Reviewed-by: Damien Neil <dneil@google.com>
  3. compiler/protogen, cmd/protoc-gen-go: use alternative comments API

    dsnet committed Aug 6, 2019
    This is a breaking change. High-level protogen API changes:
    * remove GeneratedFile.PrintLeadingComments method
    * add {Message,Field,Oneof,Enum,EnumValue,Service,Method}.Comments field
    * add CommentSet and Comments type
    
    CL/183157 added protoreflect.SourceLocations and it was discovered
    that there can actually be duplicate locations for certain paths.
    For that reason, we decided not to expose any helper methods
    for looking up locations by path since it is unclear which location
    to return if multiple matches.
    
    The protogen.GeneratedFile.PrintLeadingComments has a similar dilemma
    where it also needs to figure out what to do when duplicates exist.
    Previously, it just chooses the first one with comments,
    which may not be the right choice in a given context.
    
    Analysis of current PrintLeadingComments usage shows that it is only
    ever used (except once) for descriptor declarations.
    In the case of descriptor declarations, they are guaranteed by protoc
    to have only location.
    
    Thus, we avoid the duplicate location problem by:
    * Providing a CommentSet for every descriptor. The CommentSet contains
    a set of leading and trailing comments of the Comments type.
    * The Comments.String method knows how to interpret the comments
    as provided by protoc and format them as // prefixed line comments.
    * Values of the Comments type can be passed to the P method.
    
    We drop direct support printing leading comments for non-descriptor locations,
    but the exposure of the Comments type makes it easy for users to manually
    handle other types of comments themselves.
    
    Change-Id: Id4851456dc4e64d76bd6a30e8ad6137408dfb27a
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189198
    Reviewed-by: Damien Neil <dneil@google.com>
  4. cmd/protoc-gen-go: group extension variable declarations

    dsnet committed Aug 6, 2019
    For better readability in godoc, group extension fields by the
    target message that they are extending.
    
    Change-Id: Icc0a247b37639e3dbf7a107810923b8ca8294724
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189257
    Reviewed-by: Damien Neil <dneil@google.com>
Commits on Aug 6, 2019
  1. .gitignore: add policy for new entries

    dsnet committed Aug 6, 2019
    Change-Id: Ib3592d0ed265ca75703eb2dceb9f26a6dbecfcb7
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189197
    Reviewed-by: Damien Neil <dneil@google.com>
  2. cmd/protoc-gen-go: group enum map vars in blocks

    dsnet committed Aug 6, 2019
    Since the enum maps are here to stay, group the declarations together
    in a var block for better readability in godoc.
    
    Change-Id: I9a313266539e9a60781f98b80a5293379f82607b
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189077
    Reviewed-by: Damien Neil <dneil@google.com>
  3. cmd/protoc-gen-go: group default consts and vars in blocks

    dsnet committed Aug 6, 2019
    Group the default constant and variable declarations together in a block
    for better readability in godoc.
    
    Change-Id: I6b62f5374f0302d0f7cb224cbe34102359c8c51d
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189057
    Reviewed-by: Damien Neil <dneil@google.com>
  4. all: remove dead code

    dsnet committed Aug 5, 2019
    Change-Id: I1344d6afca9d3348db849c2b5f387ac18b80d2ba
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189021
    Reviewed-by: Damien Neil <dneil@google.com>
Commits on Aug 5, 2019
  1. internal/filedesc, internal/filetype: rename {Desc,Type}Builder as Bu…

    dsnet committed Aug 5, 2019
    …ilder
    
    Reduce the stutter in the name since the type of Builder
    is obvious from the package it is from.
    
    Change-Id: I0046a5122717536cc6bb5ebdb32b67a1560cfc23
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189020
    Reviewed-by: Damien Neil <dneil@google.com>
  2. test.bash: add -failfast flag

    dsnet committed Aug 5, 2019
    Rather than waiting for all tests for all Go versions to finish
    only to find that there was some minor breakage,
    fail fast so that we stop wasting time.
    
    Change-Id: Ie255ceb5ac2cbdc598a074c6da281f5e49eb1326
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189019
    Reviewed-by: Damien Neil <dneil@google.com>
  3. internal/impl: defer evaluation of weak reference until actual use

    dsnet committed Aug 5, 2019
    Suppose some init logic performs protobuf reflection.
    If so, it will cause the table-driven logic for protobuf reflection
    to be initialized. This is problematic for weak fields since we
    can not be certain that all weak references have been registered
    at this point in time. This is a fundamental issue with with weak
    dependencies, since it means that we cannot enforce any ordering
    constraints on the weak dependency unless we directly import the weakly
    referenced package (which would defeat the point of weak imports).
    
    Alleviate the problem by pushing evaluation of weak reference to
    actual usage. This does not completely fix the problem,
    but signifcantly reduces the probability of it being problematic.
    In general, people should avoid interacting with weak fields at init time.
    
    Change-Id: Iebaefddde8cf07b5cd7dee49b7015b05b5428618
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/188980
    Reviewed-by: Damien Neil <dneil@google.com>
  4. internal/filedesc: defer evaluation of weak reference until actual use

    dsnet committed Aug 5, 2019
    Suppose some init logic performs protobuf reflection.
    If so, it will cause the lazy descriptor init logic to be executed.
    This is problematic for weak fields since we can not be certain that
    all weak references have been registered at this point in time.
    This is a fundamental issue with with weak dependencies,
    since it means that we cannot enforce any ordering constraints
    on the weak dependency unless we directly import the weakly referenced package
    (which would defeat the point of weak imports).
    
    Alleviate the problem by pushing evaluation of weak reference to
    actual usage. This does not completely fix the problem,
    but signifcantly reduces the probability of it being problematic.
    In general, people should avoid interacting with weak fields at init time.
    
    Change-Id: Ie5957ddedd61333e72ee9a1bba0c53dace65547c
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/188982
    Reviewed-by: Damien Neil <dneil@google.com>
  5. internal/impl: fix race over messageState.mi

    dsnet committed Jul 31, 2019
    The messageState.mi field is atomically checked and set
    in generated code to the *MessageInfo associated with that message.
    However, the messageState type accesses the mi field without
    any atomic loads, thus being a potential race.
    We fix this by always calling a messageInfo method that performs
    a atomic.LoadPointer on the *MessageInfo.
    
    There is no performance effect from this change on x86 since
    an atomic.LoadPointer is identical to a MOV instruction.
    From an assembly perspective, there was no memory race previously.
    However, the lack of an atomic.LoadPointer meant that the compiler
    could in theory reorder the "normal" load to produce truly racy code.
    
    Change-Id: I8afefaf35c1916872781abc0239cbb63d62edf16
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189017
    Reviewed-by: Damien Neil <dneil@google.com>
  6. cmd/protoc-gen-go: remove XXX_OneofWrappers

    dsnet committed Jul 19, 2019
    Change-Id: I31a311c9ea24e959d5d641c66c4ee77f0c98a2ed
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186917
    Reviewed-by: Damien Neil <dneil@google.com>
  7. cmd/protoc-gen-go: remove XXX_NoUnkeyedLiteral

    dsnet committed Jul 19, 2019
    Change-Id: Ie098db74bab580903d813de05e9d015ea4b5ac75
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186898
    Reviewed-by: Damien Neil <dneil@google.com>
  8. cmd/protoc-gen-go: group generation of internal fields together

    dsnet committed Aug 5, 2019
    These were originally kept separate to assist Google-internal patches,
    but it turns out that Google-internal patches do not use the
    genMessageInternalFields function.
    
    Change-Id: Idfa962b943d3bede9982b5b0875ba90c86c6d181
    Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/188979
    Reviewed-by: Damien Neil <dneil@google.com>
You can’t perform that action at this time.