Roll serde: 1.0.219 => 1.0.225 in //third_party/rust. [chromium/src : main]
Łukasz Anforowicz (Gerrit)
Łukasz Anforowicz added 1 comment![]( "Open in Gerrit")
@dcheng, can you PTAL? Assigning directly to you because this needs a review from `build/rust/OWNERS`:
* There are some changes in `build.rs`. The changes look okay (i.e. hermetic), but they require:
* Setting `CARGO_PKG_VERSION_PATCH` environment variable in `cargo_crate.gni`
* Tweaking `gnrt_config.toml` to indicate `build_script_outputs`
* Because of splitting `serde` into `serde_core` + `serde`, we also needed some additional manual tweaks:
* We can now say `allow_unsafe = false` for `serde`
* And we also need to update `components/cronet/android/dependencies.txt`
Related details
- Daniel Cheng
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Daniel Cheng (Gerrit)
Daniel Cheng voted and added 1 comment![]( "Open in Gerrit")
Votes added by Daniel Cheng
| Code-Review | +1 |
1 comment
- Łukasz Anforowicz
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Łukasz Anforowicz (Gerrit)
Łukasz Anforowicz voted and added 1 comment![]( "Open in Gerrit")
Votes added by Łukasz Anforowicz
| Auto-Submit | +1 |
1 comment
+@aymanm for `//components/cronet/android/dependencies.txt` - PTAL?
Related details
- Mohannad Farrag
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Daniel Cheng (Gerrit)
Daniel Cheng voted Owners-Override+1![]( "Open in Gerrit")
- Mohannad Farrag
- Łukasz Anforowicz
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Chromium LUCI CQ (Gerrit)
Chromium LUCI CQ submitted the change![]( "Open in Gerrit")
Change information
Roll serde: 1.0.219 => 1.0.225 in //third_party/rust.
This CL has been created semi-automatically. The expected review
process and other details can be found at
//tools/crates/create_update_cl.md
Updated crates:
* serde: 1.0.219 => 1.0.225; https://docs.rs/crate/serde/1.0.225
* serde_derive: 1.0.219 => 1.0.225;
https://docs.rs/crate/serde_derive/1.0.225
New crates:
* serde...@1.0.225; https://docs.rs/crate/serde_core/1.0.225
- M build/rust/cargo_crate.gni
- M components/cronet/android/dependencies.txt
- M third_party/rust/chromium_crates_io/Cargo.lock
- M third_party/rust/chromium_crates_io/gnrt_config.toml
- M third_party/rust/chromium_crates_io/supply-chain/config.toml
- M third_party/rust/chromium_crates_io/vendor/serde-v1/.cargo_vcs_info.json
- M third_party/rust/chromium_crates_io/vendor/serde-v1/Cargo.lock
- M third_party/rust/chromium_crates_io/vendor/serde-v1/Cargo.toml
- M third_party/rust/chromium_crates_io/vendor/serde-v1/Cargo.toml.orig
- M third_party/rust/chromium_crates_io/vendor/serde-v1/README.md
- M third_party/rust/chromium_crates_io/vendor/serde-v1/build.rs
- M third_party/rust/chromium_crates_io/vendor/serde-v1/crates-io.md
- M third_party/rust/chromium_crates_io/vendor/serde-v1/src/integer128.rs
- M third_party/rust/chromium_crates_io/vendor/serde-v1/src/lib.rs
- M third_party/rust/chromium_crates_io/vendor/serde-v1/src/private/de.rs
- M third_party/rust/chromium_crates_io/vendor/serde-v1/src/private/mod.rs
- M third_party/rust/chromium_crates_io/vendor/serde-v1/src/private/ser.rs
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/.cargo-checksum.json
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/.cargo_vcs_info.json
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/Cargo.lock
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/Cargo.toml
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/Cargo.toml.orig
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/LICENSE-APACHE
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/LICENSE-MIT
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/README.md
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/build.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/de/ignored_any.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/de/impls.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/de/mod.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/de/value.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/format.rs
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/lib.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/macros.rs
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/private/content.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/private/doc.rs
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/private/mod.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/private/seed.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/private/size_hint.rs
- A third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/private/string.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/ser/fmt.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/ser/impls.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/ser/impossible.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/ser/mod.rs
- R third_party/rust/chromium_crates_io/vendor/serde_core-v1/src/std_error.rs
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/.cargo_vcs_info.json
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/Cargo.lock
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/Cargo.toml
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/Cargo.toml.orig
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/README.md
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/crates-io.md
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/src/de.rs
- A third_party/rust/chromium_crates_io/vendor/serde_derive-v1/src/deprecated.rs
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/src/dummy.rs
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/src/internals/ast.rs
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/src/internals/attr.rs
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/src/lib.rs
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/src/pretend.rs
- M third_party/rust/chromium_crates_io/vendor/serde_derive-v1/src/ser.rs
- M third_party/rust/serde/v1/BUILD.gn
- M third_party/rust/serde/v1/README.chromium
- A third_party/rust/serde_core/v1/BUILD.gn
- A third_party/rust/serde_core/v1/README.chromium
- M third_party/rust/serde_derive/v1/BUILD.gn
- M third_party/rust/serde_derive/v1/README.chromium
Code-Review: +1 by Daniel Cheng
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Mohannad Farrag (Gerrit)
Mohannad Farrag added 1 comment![]( "Open in Gerrit")
+@aymanm for `//components/cronet/android/dependencies.txt` - PTAL?
Is it possible to revert this CL? The new version of `serde` has introduced some complications to our Android pipeline because of this line:
```
include!(concat!(env!("OUT_DIR"), "/private.rs"));
```
`/private.rs` is generated via the build_script. We currently support the usual case of `build_scripts` where it generates a bunch of `--cfg` and `--features` that are passed to the build system afterwards. However, passing a rust file that is generated from build scripts is something that we have never encountered before and has broken our pipeline. It's also important to mention that this version has not propagated to AOSP yet, so the rust folk in AOSP might not have faced this problem yet too. We expected that this will happen at some point (go/rust-assumptions-for-gn2bp) but I guess now is the time.
So if possible, would it be okay to revert this in the meantime while I work on adding support for this just to unblock our imports?
Related details
- Łukasz Anforowicz
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Matthew Riley (Gerrit)
Matthew Riley added 1 comment![]( "Open in Gerrit")
Mohannad Farrag+@aymanm for `//components/cronet/android/dependencies.txt` - PTAL?
Is it possible to revert this CL? The new version of `serde` has introduced some complications to our Android pipeline because of this line:
```
include!(concat!(env!("OUT_DIR"), "/private.rs"));
````/private.rs` is generated via the build_script. We currently support the usual case of `build_scripts` where it generates a bunch of `--cfg` and `--features` that are passed to the build system afterwards. However, passing a rust file that is generated from build scripts is something that we have never encountered before and has broken our pipeline. It's also important to mention that this version has not propagated to AOSP yet, so the rust folk in AOSP might not have faced this problem yet too. We expected that this will happen at some point (go/rust-assumptions-for-gn2bp) but I guess now is the time.
So if possible, would it be okay to revert this in the meantime while I work on adding support for this just to unblock our imports?
Hi Mohannad, how large a change do you think it will be to accommodate this? i.e. if we revert, for how long are you asking us to hold the roll?
Related details
- Łukasz Anforowicz
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Łukasz Anforowicz (Gerrit)
Łukasz Anforowicz added 1 comment![]( "Open in Gerrit")
Mohannad Farrag+@aymanm for `//components/cronet/android/dependencies.txt` - PTAL?
Is it possible to revert this CL? The new version of `serde` has introduced some complications to our Android pipeline because of this line:
```
include!(concat!(env!("OUT_DIR"), "/private.rs"));
````/private.rs` is generated via the build_script. We currently support the usual case of `build_scripts` where it generates a bunch of `--cfg` and `--features` that are passed to the build system afterwards. However, passing a rust file that is generated from build scripts is something that we have never encountered before and has broken our pipeline. It's also important to mention that this version has not propagated to AOSP yet, so the rust folk in AOSP might not have faced this problem yet too. We expected that this will happen at some point (go/rust-assumptions-for-gn2bp) but I guess now is the time.
So if possible, would it be okay to revert this in the meantime while I work on adding support for this just to unblock our imports?
We have another weekly crate update in progress, so to avoid mid-air collisions I'll wait until those CLs land (in a day or two) and then I can try reverting.
Related details
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Łukasz Anforowicz (Gerrit)
Łukasz Anforowicz added 1 comment![]( "Open in Gerrit")
Mohannad Farrag+@aymanm for `//components/cronet/android/dependencies.txt` - PTAL?
Łukasz AnforowiczIs it possible to revert this CL? The new version of `serde` has introduced some complications to our Android pipeline because of this line:
```
include!(concat!(env!("OUT_DIR"), "/private.rs"));
````/private.rs` is generated via the build_script. We currently support the usual case of `build_scripts` where it generates a bunch of `--cfg` and `--features` that are passed to the build system afterwards. However, passing a rust file that is generated from build scripts is something that we have never encountered before and has broken our pipeline. It's also important to mention that this version has not propagated to AOSP yet, so the rust folk in AOSP might not have faced this problem yet too. We expected that this will happen at some point (go/rust-assumptions-for-gn2bp) but I guess now is the time.
So if possible, would it be okay to revert this in the meantime while I work on adding support for this just to unblock our imports?
We have another weekly crate update in progress, so to avoid mid-air collisions I'll wait until those CLs land (in a day or two) and then I can try reverting.
FWIW I was able to revert locally, but I haven't uploaded yet, because I am waiting for https://crrev.com/c/6977866 to land and get out of the way first (it hasn't landed yet because the tree seems to be having some trouble today and got closed multiple times because of MSAN issues).
Related details
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Mohannad Farrag (Gerrit)
Mohannad Farrag added 1 comment![]( "Open in Gerrit")
Mohannad Farrag+@aymanm for `//components/cronet/android/dependencies.txt` - PTAL?
Łukasz AnforowiczIs it possible to revert this CL? The new version of `serde` has introduced some complications to our Android pipeline because of this line:
```
include!(concat!(env!("OUT_DIR"), "/private.rs"));
````/private.rs` is generated via the build_script. We currently support the usual case of `build_scripts` where it generates a bunch of `--cfg` and `--features` that are passed to the build system afterwards. However, passing a rust file that is generated from build scripts is something that we have never encountered before and has broken our pipeline. It's also important to mention that this version has not propagated to AOSP yet, so the rust folk in AOSP might not have faced this problem yet too. We expected that this will happen at some point (go/rust-assumptions-for-gn2bp) but I guess now is the time.
So if possible, would it be okay to revert this in the meantime while I work on adding support for this just to unblock our imports?
Łukasz AnforowiczWe have another weekly crate update in progress, so to avoid mid-air collisions I'll wait until those CLs land (in a day or two) and then I can try reverting.
FWIW I was able to revert locally, but I haven't uploaded yet, because I am waiting for https://crrev.com/c/6977866 to land and get out of the way first (it hasn't landed yet because the tree seems to be having some trouble today and got closed multiple times because of MSAN issues).
I expect this to take around a week. I've already managed to get our pipeline to be green with local changes. I'd still need to clean-up my local changes, upload them for review and confirm that everything goes as expected. So a week is a maximum that I'll ask of you. If possible
Related details
- Łukasz Anforowicz
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Mohannad Farrag (Gerrit)
Mohannad Farrag added 1 comment![]( "Open in Gerrit")
Mohannad Farrag+@aymanm for `//components/cronet/android/dependencies.txt` - PTAL?
Łukasz AnforowiczIs it possible to revert this CL? The new version of `serde` has introduced some complications to our Android pipeline because of this line:
```
include!(concat!(env!("OUT_DIR"), "/private.rs"));
````/private.rs` is generated via the build_script. We currently support the usual case of `build_scripts` where it generates a bunch of `--cfg` and `--features` that are passed to the build system afterwards. However, passing a rust file that is generated from build scripts is something that we have never encountered before and has broken our pipeline. It's also important to mention that this version has not propagated to AOSP yet, so the rust folk in AOSP might not have faced this problem yet too. We expected that this will happen at some point (go/rust-assumptions-for-gn2bp) but I guess now is the time.
So if possible, would it be okay to revert this in the meantime while I work on adding support for this just to unblock our imports?
Łukasz AnforowiczWe have another weekly crate update in progress, so to avoid mid-air collisions I'll wait until those CLs land (in a day or two) and then I can try reverting.
Mohannad FarragFWIW I was able to revert locally, but I haven't uploaded yet, because I am waiting for https://crrev.com/c/6977866 to land and get out of the way first (it hasn't landed yet because the tree seems to be having some trouble today and got closed multiple times because of MSAN issues).
I expect this to take around a week. I've already managed to get our pipeline to be green with local changes. I'd still need to clean-up my local changes, upload them for review and confirm that everything goes as expected. So a week is a maximum that I'll ask of you. If possible
If it's too much of a hassle, then we can just fix-forward.
Łukasz Anforowicz (Gerrit)
Łukasz Anforowicz added 1 comment![]( "Open in Gerrit")
Mohannad Farrag+@aymanm for `//components/cronet/android/dependencies.txt` - PTAL?
Łukasz AnforowiczIs it possible to revert this CL? The new version of `serde` has introduced some complications to our Android pipeline because of this line:
```
include!(concat!(env!("OUT_DIR"), "/private.rs"));
````/private.rs` is generated via the build_script. We currently support the usual case of `build_scripts` where it generates a bunch of `--cfg` and `--features` that are passed to the build system afterwards. However, passing a rust file that is generated from build scripts is something that we have never encountered before and has broken our pipeline. It's also important to mention that this version has not propagated to AOSP yet, so the rust folk in AOSP might not have faced this problem yet too. We expected that this will happen at some point (go/rust-assumptions-for-gn2bp) but I guess now is the time.
So if possible, would it be okay to revert this in the meantime while I work on adding support for this just to unblock our imports?
Łukasz AnforowiczWe have another weekly crate update in progress, so to avoid mid-air collisions I'll wait until those CLs land (in a day or two) and then I can try reverting.
Mohannad FarragFWIW I was able to revert locally, but I haven't uploaded yet, because I am waiting for https://crrev.com/c/6977866 to land and get out of the way first (it hasn't landed yet because the tree seems to be having some trouble today and got closed multiple times because of MSAN issues).
Mohannad FarragI expect this to take around a week. I've already managed to get our pipeline to be green with local changes. I'd still need to clean-up my local changes, upload them for review and confirm that everything goes as expected. So a week is a maximum that I'll ask of you. If possible
If it's too much of a hassle, then we can just fix-forward.
Yeah, sorry, but the revert indeed does seem like quite a bit of trouble. I tried to actually run `gn gen` after the revert and it failed - this seems to be caused by the following transitive dependency on the rolled package (i.e. the revert is difficult and would necessitate cascading/follow-up reverts/changes [at least also reverting the roll of `serde_json`):
```
$ tools/crates/run_gnrt.py vendor
Finished `release` profile [optimized] target(s) in 0.19s
Running `out/gnrt/target/release/gnrt vendor`
Vendoring crates from third_party/rust/chromium_crates_io
Error: running cargo metadata
Caused by:
0: `cargo metadata` execution failed
1: `cargo metadata` exited with an error: error: failed to select a version for `serde`.
... required by package `serde_json v1.0.145`
... which satisfies dependency `serde_json = "^1.0.138"` (locked to 1.0.145) of package `llguidance v1.2.0`
... which satisfies dependency `llguidance = "^1.0.0"` (locked to 1.2.0) of package `chromium v0.1.0 (/usr/local/google/home/lukasza/src/chromium2/src/third_party/rust/chromium_crates_io)`
versions that meet the requirements `^1.0.220` are: 1.0.226, 1.0.225, 1.0.224, 1.0.223, 1.0.222, 1.0.221, 1.0.220
all possible versions conflict with previously selected packages.
previously selected package `serde v1.0.219`
... which satisfies dependency `serde = "^1.0.219"` (locked to 1.0.219) of package `chromium v0.1.0 (/usr/local/google/home/lukasza/src/chromium2/src/third_party/rust/chromium_crates_io)`
failed to select a version for `serde` which could resolve this conflict
```
Related details
Code-Coverage
Code-Owners
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |