It appears everything was already working on Java 11, except
build-specific and testing issues. Updating to Netty 4.1.30 (#4940)
probably fixed the last true Java 11 incompatibility.
Fixes#4933
This PR adds an automatic gradle format checker and reformats all the *.gradle files. After this, new changes to *.gradle files will fail to build if not in good format, just like checkStyle failure.
The new jmh plugin fixes a warning for the newer version of Gradle.
The new AppEngine plugin still produces a warning, but updating it
anyway so people know that upgrading the plugin doesn't fix the problem.
The new android-maven plugin fixes a build problem with the newer
Gradle.
The Visual Studio fixes were necessary starting ~4.4.
https://github.com/gradle/gradle-native/issues/34#issuecomment-335222096
describes the change in behavior.
There's nothing immediately being used as part of this update. It's just
to keep us current and to get us over that Visual Studio change hump.
This change puts the compiler test.proto file in a directory that matches it's path. The current proto package has a namespace collision with the grpc.testing proto in interop-testing. Thus, this PR:
* change the package of test.proto to be grpc.testing.compiler
* moves the test.proto into the matching grpc/testing/compiler/test.proto path
* updates the generated code.
previously `Import` fails because it gets turned into a method named
`import`. This PR makes the method be named `import_`, everything else
stays the same, such as the name in the method descriptor.
Note: `iMport` or `iMPORT` or any variation of capitalizations that is
not `Import` always worked. `Import` gets translated into `import`
because of our attempts to camel case the names.
Previously if protobuf-generated code triggered ErrorProne we'd have to disable
the failing check for all code in that task. With -XepExcludedPaths we can
disable the ErrorProne-checking just for protobuf. Note that we continue using
ErrorProne on our generated code. Also note this only applies to ErrorProne
checks; JDK checks still require task-level disabling.
This moves away from the global String-based Span name registry which
is not as flexible as we desire.
Also renamed the option name to be more accurate. This is not
API-breaking because the origianl addition to MethodDescriptor and
code-gen didn't make it into the 1.7.0 release.
* MethodDescriptor is lazy loaded, so protobuf loading only happens on demand. This also means tracing registration happens on demand.
* The names of the getters all being with `method`. This makes it harder for autocomplete to pick them up.
* A new field is used, which matches the getter name. Rather than make the new-getters reference the old-fields, make the old-fields reference the new getters. This makes removal of the old-fields a simple operation.
* The getters may not be inlineable, but thats an easy fix if it ends up being a problem. Not worth premature optimization (but is worth future work).
The expected timeline for this is adding this to the 1.8 cut, and deprecating the old-fields. They will be removed in 1.9.
This is a more favorable approach than #3467. Doing the registration
in MethodDescriptor should allow us to deregister in case the
generated stub and its MethodDescriptors are garbage-collected
routinely, e.g., if they are loaded by a separate ClassLoader.
This bump changelist is applied a bit late with respect to the
1.6.0 branch cut. Look at the 1.6.0 to see the source of truth of
where it was cut. Do not assume it is the commit that precedes
this one.
This fixes sign-compare and maybe-unintialized. An unused-value warning
remains.
I changed LogHelper to always call abort so the compiler would know the
method does not return, which fixed the maxbe-uninitialized warning.
Bazel third party dependencies are specified in repositories.bzl which
gives the consumer the ability to opt-out of any dependencies they use
directly in their own project.
Fixes#2756
The code uses std::back_insert_iterator which is part of the <iterator>
header. The header is not included though.
We (bazel) noticed the build failing on Windows when using the Visual Studio
C++ compiler.
Thomas Broyer