This PR implements dylib linkage against the standard library behind a
feature flag
`--@rules_rust//rust/settings:experimental_use_dylib_linkage`.
The main part of this feature is
[here](https://github.com/bazelbuild/rules_rust/pull/2414/files#diff-2a806da393e47c07ffe67c78ace69eb488b4ac44b029a46d8237b8e2a05637beR258)
where we skip exporting static rust stdlibs and export only `libstd.so`
instead.
This feature is useful when the subset of libstd being statically linked
to downstream shared libraries and binaries is **larger** than the
entire dylib version of libstd. The following diagram is the high level
of what dylib linkage is trying to achieve.
![Untitled Diagram
drawio](https://github.com/bazelbuild/rules_rust/assets/13268391/d19f18f5-c2d1-4ddc-b170-773a6004f732)
Running the feature against `android_binary` yields a size reduction on
the shared library produced by `android_binary` because it doesn't
statically link the rust stdlibs anymore.
```
> bazel build //:android_app --config=android_x86_64
> unzip -l bazel-bin/android_app.apk
Archive: bazel-bin/android_app.apk
Length Date Time Name
--------- ---------- ----- ----
1381968 2010-01-01 00:00 lib/x86_64/libandroid_app.so <--- static link with rust stdlibs
--------- -------
1390294 9 files
```
```
> bazel build //:android_app --config=android_x86_64 --config=dylib_linkage
> unzip -l bazel-bin/android_app.apk
Archive: bazel-bin/android_app.apk
Length Date Time Name
--------- ---------- ----- ----
8080 2010-01-01 00:00 lib/x86_64/libandroid_app.so <--- reduced size because of dynamic linking
13055776 2010-01-01 00:00 lib/x86_64/libstd-8d416d49cf02ecea.so
--------- -------
13072400 10 files
```
Here, the benefit comes when there are enough shared libraries statically linking against the rust stdlibs. "Enough" here means that the total up size of those libraries being more than just the entire `libstd.so`.
TODO: I'm leaving this PR without unit tests until I get some feedback or suggestions on my approach.
---------
Co-authored-by: scentini <rosica@google.com>
This PR consolidates rust_prost_library and rust_tonic_library into one rule; `rust_prost_library`. `rust_prost_library` will generate tonic services if you provide a `tonic_plugin` in the toolchain definition. If you do not provide that plugin and you try to build a proto with services, it will print a warning that you should add a `tonic_plugin`.
This PR also handles extension-only proto files. Prost does not generate a file if there are no messages, enums, or services and it appears that Prost doesn't even support proto2 extensions. So to work around this issue, protoc_wrapper will generate an empty `.rs` file in the case that there are only extensions defined in a file.
Closes: #2046
* Setup Prost and Tonic rules.
* Regenerate documentation
* Add more tests.
* Add more tests and address feedback.
* Regenerate documentation
* Add to proto docs page.
* Bump min supported bazel version.
* buildifier
* Always enable backtracing.
* Add more info to failing rename.
* Set min rust version to 1.62.0
* Handle rust keywords as package names.
* exclude windows from prost toolchain support.
* buildifier
* redundant
* Use prost-types to parse the file descriptor set.
* Cleanup and more tests.
* Move prost-types to toolchain definition.
* fix rustfmt
* Add example of building protos with complex imports
* impl Display
* Fix all tests
* Add rust checks for the complex import protos.
* Address feedback
* Fix buildifier
* Depend on remote-apis repo.
* Remove bazel remote apis due to file length and transitive dependency issues.
* Update patch and docs.
* Regenerate documentation
* Regenerate documentation
* Update docs.
---------
Co-authored-by: Daniel Wagner-Hall <dwagnerhall@apple.com>
In this PR we remove hardcoded assumption about where rust-analyzer support code looks for rustc sources, and instead read that information from the `rust_toolchain.rustc_src`. We also handle the case when rustc sources are actually in the main repository, so there is no need to use the `__EXEC_ROOT__/` prefix for its path.
Notable changes in this PR:
- `crate_universe` `lockfile` attributes are now rendered as json files instead of starlark dumps
- The `cargo-raze` dependenciy has been updated to a pin which implements the required sorting and de-serialization.
- Formatted `use` declarations
- Updated dependencies
- `CARGO` and `RUSTC` environment variables are now ignored in determining the digest. This should be safe given that `cargo version` is an input to generating the lockfile hash.
- `repository_template` has been renamed to `crate_registry_template`, which is more correct.
- The [json](https://docs.bazel.build/versions/master/skylark/lib/json.html) module is now used to handle generating the config `.json` file
* Added bootstrap script for crate_universe and github action for auto-releasing new binaries
* Addressed PR feedback
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
* Updated local dev documentation
* Add announce_rc to crate_universe.bazelrc
* Addressed buildifier defect
* Addressed additional user feedback
* Apply suggestions from code review
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
* Fixed missing extension for windows.
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
The use of `BUILD`/`WORKSPACE` vs `BUILD.bazel`/`WORKSPACE.bazel` was inconsistent across the repo. This PR updates all files without the `.bazel` extension to use it (which has the higher priority over the two styles. see [here](https://docs.bazel.build/versions/master/build-ref.html#packages)).
Additionally, this PR contains buildifier fixes