52 lines
1.4 KiB
Go
Raw Normal View History

// Copyright 2018 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// The protoc-gen-go binary is a protoc plugin to generate Go code for
// both proto2 and proto3 versions of the protocol buffer language.
//
// For more information about the usage of this plugin, see:
// https://developers.google.com/protocol-buffers/docs/reference/go-generated
package main
import (
"errors"
"flag"
runtime/protoimpl, cmd/protoc-gen-go: support release versioning 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>
2019-07-10 00:15:35 -07:00
"fmt"
"os"
"path/filepath"
gengo "google.golang.org/protobuf/cmd/protoc-gen-go/internal_gengo"
"google.golang.org/protobuf/compiler/protogen"
"google.golang.org/protobuf/internal/version"
)
compiler/protogen: require that the import path be specified Since the release of v1.20, we have warned that it be required that the import path for every generated package be specified. This CL simplifies the mechanism for specifying such information to just the "M" command-line flags and the "go_package" options in the .proto source files, where the former takes precedence over the latter. Changes made: * Remove "import_prefix" and "import_path" flags. * Make the Go import path and package name derivation logic simpler where both "M" flags and "go_package" options are parsed the same way by calling the common splitImportPathAndPackageName function, and where "M" flags take precedence over "go_package" options. The exception to this occurs when neither "M" nor "go_package" specify an explicit Go package name, where the derivation may be non-intuitive. See the "NOTE" comment for the rationale for this behavior, which actually matches what was already the case. * Remove the pathTypeLegacy output mode and make pathTypeImport the default. The pathTypeLegacy mode becomes even more non-sensible now that we require that the import path always be provided. * Remove the baseName function. After deleting unsupported functionality, this seems to only be used by GeneratedFile.QualifiedGoIdent. However, that method does not need to create stable package names since they are only used locally within the generated file. They only need to guarantee the property of validity and uniqueness. * Remove the warn function since there are no more warnings. Change-Id: Ic95fb3cde5ffcb71bbcc829fcff34369758cebef Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/301953 Trust: Joe Tsai <joetsai@digital-static.net> Reviewed-by: Damien Neil <dneil@google.com>
2021-03-16 03:20:52 -07:00
const grpcDocURL = "https://grpc.io/docs/languages/go/quickstart/#regenerate-grpc-code"
func main() {
runtime/protoimpl, cmd/protoc-gen-go: support release versioning 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>
2019-07-10 00:15:35 -07:00
if len(os.Args) == 2 && os.Args[1] == "--version" {
fmt.Fprintf(os.Stdout, "%v %v\n", filepath.Base(os.Args[0]), version.String())
os.Exit(0)
runtime/protoimpl, cmd/protoc-gen-go: support release versioning 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>
2019-07-10 00:15:35 -07:00
}
var (
compiler/protogen: require that the import path be specified Since the release of v1.20, we have warned that it be required that the import path for every generated package be specified. This CL simplifies the mechanism for specifying such information to just the "M" command-line flags and the "go_package" options in the .proto source files, where the former takes precedence over the latter. Changes made: * Remove "import_prefix" and "import_path" flags. * Make the Go import path and package name derivation logic simpler where both "M" flags and "go_package" options are parsed the same way by calling the common splitImportPathAndPackageName function, and where "M" flags take precedence over "go_package" options. The exception to this occurs when neither "M" nor "go_package" specify an explicit Go package name, where the derivation may be non-intuitive. See the "NOTE" comment for the rationale for this behavior, which actually matches what was already the case. * Remove the pathTypeLegacy output mode and make pathTypeImport the default. The pathTypeLegacy mode becomes even more non-sensible now that we require that the import path always be provided. * Remove the baseName function. After deleting unsupported functionality, this seems to only be used by GeneratedFile.QualifiedGoIdent. However, that method does not need to create stable package names since they are only used locally within the generated file. They only need to guarantee the property of validity and uniqueness. * Remove the warn function since there are no more warnings. Change-Id: Ic95fb3cde5ffcb71bbcc829fcff34369758cebef Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/301953 Trust: Joe Tsai <joetsai@digital-static.net> Reviewed-by: Damien Neil <dneil@google.com>
2021-03-16 03:20:52 -07:00
flags flag.FlagSet
plugins = flags.String("plugins", "", "deprecated option")
)
protogen.Options{
ParamFunc: flags.Set,
}.Run(func(gen *protogen.Plugin) error {
if *plugins != "" {
compiler/protogen: require that the import path be specified Since the release of v1.20, we have warned that it be required that the import path for every generated package be specified. This CL simplifies the mechanism for specifying such information to just the "M" command-line flags and the "go_package" options in the .proto source files, where the former takes precedence over the latter. Changes made: * Remove "import_prefix" and "import_path" flags. * Make the Go import path and package name derivation logic simpler where both "M" flags and "go_package" options are parsed the same way by calling the common splitImportPathAndPackageName function, and where "M" flags take precedence over "go_package" options. The exception to this occurs when neither "M" nor "go_package" specify an explicit Go package name, where the derivation may be non-intuitive. See the "NOTE" comment for the rationale for this behavior, which actually matches what was already the case. * Remove the pathTypeLegacy output mode and make pathTypeImport the default. The pathTypeLegacy mode becomes even more non-sensible now that we require that the import path always be provided. * Remove the baseName function. After deleting unsupported functionality, this seems to only be used by GeneratedFile.QualifiedGoIdent. However, that method does not need to create stable package names since they are only used locally within the generated file. They only need to guarantee the property of validity and uniqueness. * Remove the warn function since there are no more warnings. Change-Id: Ic95fb3cde5ffcb71bbcc829fcff34369758cebef Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/301953 Trust: Joe Tsai <joetsai@digital-static.net> Reviewed-by: Damien Neil <dneil@google.com>
2021-03-16 03:20:52 -07:00
return errors.New("protoc-gen-go: plugins are not supported; use 'protoc --go-grpc_out=...' to generate gRPC\n\n" +
"See " + grpcDocURL + " for more information.")
}
for _, f := range gen.Files {
internal/cmd/generate-protos: initial commit Create a single binary for handling generation of protos. This replaces previous logic spread throughout the repo in: * regenerate.bash * cmd/protoc-gen-go/golden_test.go * cmd/protoc-gen-go-grpc/golden_test.go * (indirectly) internal/protogen/goldentest One of the problems with the former approaches is that they relied on a version of protoc that was specific to a developer's workstation. This meant that the result of generation was not hermetic. To address this, we rely on the hard-coded version of protobuf specified in the test.bash script. A summary of changes in this CL are: * The internal_gengo.GenerateFile and internal_gengogrpc.GenerateFile functions are unified to have consistent signatures. It seems that the former accepted a *protogen.GeneratedFile to support v1 where gRPC code was generated into the same file as the base .pb.go file. However, the same functionality can be achieved by having the function return the generated file object. * The test.bash script patches the protobuf toolchain to have properly specified go_package options in each proto source file. * The test.bash script accepts a "-regenerate" argument. * Add generation for the well-known types. Contrary to how these were laid out in the v1 repo, all the well-known types are placed in the same Go package. * Add generation for the conformance proto. * Remove regenerate.bash * Remove internal/protogen * Remove cmd/protoc-gen-go/golden_test.go * Remove cmd/protoc-gen-go-grpc/golden_test.go * Add cmd/protoc-gen-go/annotation_test.go Change-Id: I4a1a97ae6f66e2fabcf4e4d292c95ab2a2db0248 Reviewed-on: https://go-review.googlesource.com/c/164477 Reviewed-by: Damien Neil <dneil@google.com>
2019-02-27 21:46:29 -08:00
if f.Generate {
gengo.GenerateFile(gen, f)
}
}
gen.SupportedFeatures = gengo.SupportedFeatures
return nil
})
}