| Age | Commit message (Collapse) | Author |
|---|
|
am: 453a76a7f3
Change-Id: Ifcc1a007cb35fcd4095ff6d240f8ba00b8afcb77
|
|
am: bd46f6d13b
Change-Id: I4d7c234b14cd41662c09a2b989ce8d93160102cf
|
|
am: a647664c0f
Change-Id: Idcc632dce6829dea575f7a6a80888599ec927b69
|
|
Test: build
Change-Id: Iff2b2c139c68250f29c3043a20a4440aee930d4b
|
|
am: a13ae713d3
Change-Id: I6e2094d7d47b96878baaf4e460286a9670147e58
|
|
Bug: 126125118
Change-Id: I682b273697041786db356016f9d11f7af7d55c48
|
|
Bug: 120848293
Change-Id: I3a7f767615d56bfe0f2cb4c3e367763cc0fa0d39
|
|
The existing code is much more complex.
|
|
It is spec'd that way, but best practice is to avoid it.
|
|
am: eb0cd6fad6
Change-Id: I21e4ad6d4bb52d071b8ecfb6c812c45095b12827
|
|
am: a0678e25a5
Change-Id: Ib827cbf08d86aec3bccbdde775890a14bbe63d6f
|
|
am: 3a61e5431b
Change-Id: I5d831ec663b208dcc20eee4dc36a62dbd6fd3679
|
|
Bug: 33166666
Test: gerrit uploader
Change-Id: I00e6868f8e5fe1c7b75109da55fbef05bb0d588d
|
|
The generator currently uses an unintuitive and stateful algorithm
for name generation where it "fixes" name conflicts by appending "_"
to the end of the new name.
PR#657 refactored the generator code and noticed that the above
algorithm was not properly taking into account that a Get method is
generated for parent oneofs, fixing it in the same PR. While this is
more correct, this breaks users (see #780) since it means that the
generation of names can change.
This PR changes the name mangling logic to be as it was previously.
This does mean that some new proto files may be unbuildable,
but that is arguably better than breaking existing proto files.
Fixes #780
|
|
|
|
The marshaler, unmarshaler, and sizer functions are unused ever since
the underlying implementation was switched to be table-driven.
Change the function to only return the wrapper structs.
This change:
* enables generated protos to drop dependencies on certain proto types
* reduces the size of generated protos
* simplifies the implementation of oneofs in protoc-gen-go
Updates #708
|
|
Update all proto files that is obtained from the upstream repository to v3.6.1.
|
|
The current API represents scalar extension fields as *T and
repeated extension fields as []T.
However, this is not an accurate reflection of the protobuf data model.
For scalars, pointers are usually used to represent nullability. However,
in the case of extension scalars, there is no need to do so since presence
information is captured by checking whether the field is in the extension map.
For this reason, presence on extension scalars is not determined by checking
whether the returned pointer is nil, but whether HasExtension reports true.
For repeated fields, using []T means that the returned value is only a partially
mutable value. You can swap out elements, but you cannot change the length of
the original field value. On the other hand, the reflective API provides methods
on repeated field values that permit operations that do change the length.
Thus, using *[]T is a closer match to the protobuf data model.
This CL changes the implementation of extension fields to always store T
for scalars, and *[]T for repeated fields. However, for backwards compatibility,
the API continues to provide *T and []T. In theory, this could break anyone
that relies on memory aliasing for *T. However, this is unlikely since:
* use of extensions themselves are relatively rare
* if extensions are used, it is recommended practice to use a message as the
field extension and not a scalar
* relying on memory aliasing is generally not a good idiom to follow.
The expected pattern is to call SetExtension to make it explicit that a mutation
is happening on the message.
* analysis within Google demonstrates that no one is relying on this behavior.
|
|
Despite the naming, these are "internal-only" functions that are intended to
only be called from generated code for MessageSets.
Furthermore, MessageSets are themselves a deprecated feature from proto1 days,
such that descriptor.proto even warns against their use since the initial
open-source release of protocol buffers in 2008. Within Google,
there are no direct usages of these functions, and all existing
usages of MessageSets go through the new table-driven implementation.
In addition to deprecating the {Unm,M}arshalMessageSet{JSON} top-level functions,
also modify the generator to stop emitting MarshalJSON and UnmarshalJSON methods
for messages sets. The UnmarshalJSON method is not implemented and the
MarshalJSON method does not seem to be called anywhere in Google (verified by
making the method panic and doing a global test). The jsonpb package continues
to work with MessageSets.
I should note that when the table-driven implementation was open sourced
in late 2017 (see 8cc9e46429bfb16289d40d30b2ee3f4923b47345), it accidentally
removed generation of the Marshal and Unmarshal method. However, no one seemed
to have noticed that those methods were no longer generated.
|
|
|
|
Consider this case:
File 1 defines M.
File 2 publicly imports file 1.
File 3 imports file 2, and references M.
Each file is in a different Go package: P1, P2, P3.
Should the generated Go code for file 3 reference P1.M, or P2.M?
The two should be equivalent, since file 2 will contain a forwarding
declaration such as "type M = P1.M".
Historically, we've gone with the latter (P2.M). This does make sense:
A generated file only imports the packages of the files that it directly
imports.
However, this does have some mildly surprising effects. If File 3
imports files 2a and 2b, each of which publicly imports file 1, we need
to arbitrarily pick one of P2a.M or P2b.M. (Admittedly an obscure case.)
Simplify the generator a little bit (and, more importantly, make it
consistent with the v2 generator) and change to referencing public
imports directly.
|
|
Test the following case:
File 1 defines a symbol S.
File 2 publicly imports file 1.
File 3 imports file 2 and uses S.
All files in different Go packages: P1, P2, P3.
Note that the .pb.go for file 3 could import P1 or P2, since the symbol
is defined in both.
|
|
Groups were being excluded from the set of messages we generate
forwarding declarations for. Include them.
|
|
Convert all the import_public protos to proto2 to allow testing more
features.
Add usage of groups, extensions, and default values.
|
|
Parse floating-point default values and format them with fmt.Sprint.
Eliminates a minor point of inconsistency with the v2 generator.
|
|
MERGE am: ad5c1b9ef6 -s ours am: 2ee46ba360 -s ours
am: df1006f799 -s ours
Change-Id: I90edca3b74b83d6ff5100f0bac4ff5fb01c1fcd0
|
|
MERGE am: ad5c1b9ef6 -s ours
am: 2ee46ba360 -s ours
Change-Id: I44d9ec3d5b93ab03e077aab3c8dc5edf76a292f0
|
|
am: ad5c1b9ef6 -s ours
Change-Id: I3852bf24f2054b38c4a2d53b705e5257af58d035
|
|
|
|
|
|
Change-Id: I23c868d79b5a5e2ec5b4f6c048fad4e7083d3685
|
|
MERGE am: b9beca1ea0 -s ours
am: 2d25560132 -s ours
Change-Id: I631e6a4fdfe4c639d8846e2258ddf7a6d1f62d5a
|
|
MERGE
am: b9beca1ea0 -s ours
Change-Id: I9a190f0686945b15256122f64812d163fb10c9ca
|
|
Change-Id: If3134ea55ca64ccf06299aa8193e2c9984b4f589
|
|
Avoid turning comments like "//////" into "// ////".
|
|
|
|
|
|
(#724)
Permit creating a generated package named e.g., "string". Apply disambiguation
to prevent creating a local import name that conflicts with predefined
identifiers; importing package "string" will be done as:
import string1 "string"
|
|
Don't generate identifiers that conflict with predeclared identifiers,
prepend with "_" instead.
Signed-off-by: Arjun Sreedharan <asreedharan@pivotal.io>
|
|
Keep plugin imports and non-plugin imports in the same section, but
don't try to split stdlib and non-stdlib imports into different
sections. Consistent with using astutil to insert all imports from a
blank slate.
|
|
Split imports into standard library and third-party imports. Decide
between the two based on the presence of a ".", which is the same
heuristic used by goimports.
Allow plugins to register packages to import, so gRPC imports don't sit
awkwardly in a separate import () block.
|
|
Avoid interleaving plugin output with the rest of the generated code.
No functional change, but simplifies keeping the v1 and v2 generator
output identical.
|
|
We generate a single init function containing registration calls for
all the things in a .pb.go that need one (messages, extensions, etc.)
Some of these registrations are added to a list as the generator processes
the type that needs to be registered (e.g., messages.) Some are added at
the end while generating the init function (e.g., enums). Extensions
are done in both places.
Make this consistent and always generate the registration functions
during processing. This simplifies the code a bit, and makes it easier
for a new generator to be consistent with its output.
No changes to the number of init functions, just the order of
registration calls in the existing one.
|
|
We intentionally don't attach comments from the .proto source file to
the Go package declaration (since this produces strange output when
multiple .proto files in the same Go package all have comments), but
putting the comment above the package decl makes it easier to find and
keeps it from being obscured by the imports.
Also change the package comment to be generated with PrintComments
(producing // comments rather than /* */ comments) to save a few lines
of code and be internally consistent.
|
|
Some aliases generated for public imports include comments indicating
the source of the import. Fix these comments to match the name of the
imported symbol. Example changes:
-// Submessage from public import import_public/sub/a.proto
+// M_Submessage from public import import_public/sub/a.proto
type M_Submessage = sub.M_Submessage
-// Subenum from public import import_public/sub/a.proto
+// M_Subenum from public import import_public/sub/a.proto
type M_Subenum = sub.M_Subenum
-// Submessage_Subenum from public import import_public/sub/a.proto
+// M_Submessage_Submessage_Subenum from public import import_public/sub/a.proto
type M_Submessage_Submessage_Subenum = sub.M_Submessage_Submessage_Subenum
Drop the "ignoring public import of {symbol} from {file}..." comment.
This comment can be somewhat confusing, since it doesn't explain why the
import is being ignored, and it's not easy in the current generator to
get the symbol name right.
|
|
Adds cases for importing nested messages, nested enums, and oneofs.
|
|
This tag is not used by jsonpb. Future releases of protoc will stop
including a json_name field in extension descriptors.
|
|
Add a blank line after the Descriptor and XXX_WellKnownType methods.
|
|
Add a blank line between the ExtensionRangeArray and XXX_Unmarshal methods.
|
|
Put all the imports into a single block.
Before:
import proto "github.com/golang/protobuf/proto"
import fmt "fmt"
import math "math"
After:
import (
fmt "fmt"
proto "github.com/golang/protobuf/proto"
math "math"
)
Sort imports using ast.SortImports rather than doing our own sorting,
ensuring consistency with gofmt.
This is a trivial change, but allows for identical output from this
version of the generator and one which uses astutil.AddNamedImport to
patch imports into the AST.
|
