This change creates packages under src/google/protobuf/{io,stubs,testing} and moves build definitions there. Future changes will handle .../util and .../compiler, and finally src/google/protobuf.
If the user provides a `--link-objects` (or `-O`) flag that looks like it points to libprotobuf, use that for static linking instead of using the hard-coded path `../src/.libs/libprotobuf.a`. (Also, if we see such a flag, assume they want to link it statically, even if they don't provide `--compile_static_extension`.)
Similarly, if they provide a `--library-dirs=` (or `-L`), assume that is the location to search, and don't add the hard-coded path `../src/.libs`.
* Don't drop parser warnings on the floor
Fix#9343.
* Convert "missing syntax" warning to an actual warning
For some reason this warning was emitted as a log message rather than a
structured warning. Convert it to use the AddWarning API so that it gets
emitted with a file and line number by protoc, and is visible via the
error collection interface during programmatic use.
* Remove CaptureTestStderr() call
CaptureTestStderr() and GetCapturedTestStderr() have to be paired with each other.
* Adjust tests for new warnings
A few tests now produce warnings that they didn't before, but were
expecting not to see any stderr output. Adjust the tests accordingly.
Co-authored-by: Adam Cozzette <acozzette@google.com>
We already have the TypeRegistry abstraction for JSON parsing, so it lends itself well to this.
Note that this is much more useful than it would have been before C# gained pattern matching support: it's easy to imagine a switch statement/expression using pattern matching with the result of this, with cases for a set of known message types, for example.
* Switch to new provider syntax instead of structs.
* Expose files via `DefaultInfo`, and use that for `py_proto_library`.
* Several changes from buildifier.
The cmake tests are expected to fail for now due to Abseil sources missing from the distribution artifact. The tests are structured as expected failures.
These are all "toolchain-y" things, like copts, link_opts, and config_settings. These are very different from what is in //toolchain, though, so I chose the somewhat common name build_defs for the package. For now, I am only using this package for purely internal things. (Most public "defs"-type things should come from rules_proto/rules_cc, anyhow.)
