Commit Graph

10 Commits

Author SHA1 Message Date
CodemodService Bot
254d2a37ad Daily common/rust/cargo_from_buck/bin/autocargo
Reviewed By: krallin

Differential Revision: D28928316

fbshipit-source-id: 6da6c9a5321d722a3dfd816b49f3994df98c7471
2021-06-07 02:19:59 -07:00
Jeremy Fitzhardinge
c652f9a11f third-party/rust: update time to 0.2
Summary:
Time 0.2 is current, and 0.1 is long obsolete. Unfortunately there's a
large 0.1 -> 0.2 API change, so I preserved 0.1 and updated the targets of its
users. Also unfortunate that `chrono` has `oldtime` as a default feature, which
makes it use `time-0.1`'s `Duration` type. Excluding it from the features
doesn't help because every other user is specifying it by default.

Reviewed By: dtolnay

Differential Revision: D28854148

fbshipit-source-id: 0c41ac6b998dfbdcddc85a22178aadb05e2b2f2b
2021-06-03 13:52:54 -07:00
Thomas Orozco
846a983d67 thrift/lib/rust: update to Bytes 1.x
Summary:
Like it says in the title. The API between Bytes 1.x has changed a little bit,
but the concepts are basically the same, so we just need to change the
callsites that were calling `bytes()` and have them ask for `chunk()` instead.

This diff attempts to be as small as it can (and it's already quite big). I
didn't attempt to update *everything*: I only updated whatever was needed to
keep `common/rust/tools/scripts/check_all.sh` passing.

However, there are a few changes that fall out of this. I'll outline them here:

## `BufExt`

One little caveat is the `copy_to_bytes` we had on `BufExt`. This was
introduced into Bytes 1.x (under that name), but we can't use it here directly.

The reason we can't is because the instance we have is a `Cursor<Bytes>`, which
receives an implementation of `copy_from_bytes` via:

```
impl<T: AsRef<[u8]>> Buf for std::io::Cursor<T>
```

This means that implementation isn't capable of using the optimized
`Bytes::copy_from_bytes` which doesn't do a copy at all. So, instead, we need
to use a dedicated method on `Cursor<Bytes>`: `copy_or_reuse_bytes`.

## Calls to `Buf::to_bytes()`

This method is gone in Bytes 1.x, and replaced by the idiom
`x.copy_to_bytes(x.remaining())`, so I updated callsites of `to_bytes()`
accordingly.

## `fbthrift_ext`

This set of crates provides transports for Thrift calls that rely on Tokio 0.2
for I/O. Unfortunately, Tokio 0.2 uses Bytes 0.5, so that doesn't work well.

For now, I included a copy here (there was only one required, when reading from
the socket). This can be removed if we update the whole `fbthrift_ext` stack to
Bytes 1.x. fanzeyi had been wanting to update this to Tokio 1.x, but was blocked on `thrift/lib/rust` using Bytes 0.5, and confirmed that the overhead of a copy here is fine (besides, this code can now be updated to Tokio 1.x to remove the copy).

## Crates using both Bytes 0.5 & Bytes 1.x

This was mostly the case in Mononoke. That's no coincidence: this is why I'm
working on this. There, I had to make changes that consist of removing Bytes
0.5 to Bytes 1.x copies.

## Misuse of `Buf::bytes()`

Some places use `bytes()` when they probably mean to use `copy_to_bytes()`. For
now, I updated those to use `chunk()`, which keeps the behavior the same but
keeps the code buggy. I filed T91156115 to track fixing those (in all
likelihood I will file tasks for the relevant teams).

Reviewed By: dtolnay

Differential Revision: D28537964

fbshipit-source-id: ca42a614036bc3cb08b21a572166c4add72520ad
2021-05-20 09:44:41 -07:00
Stanislau Hlebik
eab97b6123 mononoke: sync changeset implementation for megarepo
Summary: First stab at implementing sync changeset functionality for megarepo.

Reviewed By: ikostia

Differential Revision: D28357210

fbshipit-source-id: 660e3f9914737929391ab1b29f891b3b5dd47638
2021-05-13 10:04:21 -07:00
Alex Hornby
da5dac311b rust: remove patch for async-compression
Summary: Upstream crate has landed my PR for zstd 1.4.9 support and made a release, so can remove this patch now.

Reviewed By: ikostia

Differential Revision: D28221163

fbshipit-source-id: b95a6bee4f0c8d11f495dc17b2737c9ac9142b36
2021-05-05 12:20:34 -07:00
Toan Mai
410f7c5c61 Imported a mysql_common patch to support FromRow for tuples up to arity 16 (#23)
Summary:
Pull Request resolved: https://github.com/facebookexperimental/rust-shed/pull/23

Pull Request resolved: https://github.com/facebookincubator/resctl/pull/8081

Pull Request resolved: https://github.com/facebookexperimental/eden/pull/82

Imported a mysql_common patch to support FromRow for tuples upto arity 16
Context: https://fburl.com/zfnw7r86

Followed the guide: https://www.internalfb.com/intern/wiki/Rust-at-facebook/Managing_fbsource_third-party_with_Reindeer/#maintaining-local-change

Reviewed By: marcelogomez

Differential Revision: D28094262

fbshipit-source-id: fed48e3950e8a3ba3d7a15407522167e5ae41a98
2021-05-05 10:32:48 -07:00
Gus Wynn
cbbb45206b slog max_level_debug -> trace
Reviewed By: Imxset21

Differential Revision: D28097080

fbshipit-source-id: 7d417f8256922926cf379d9c2fb3249f6d2544ef
2021-05-03 10:30:21 -07:00
Thomas Orozco
9c7aa6aaf7 third-party/rust: remove patches for Tokio 0.2 & Hyper 0.2
Summary:
We used to carry patches for Tokio 0.2 to add support for disabling Tokio coop
(which was necessary to make Mononoke work with it), but this was upstreamed
in Tokio 1.x (as a different implementation), so that's no longer needed. Nobody
else besides Mononoke was using this.

For Hyper we used to carry a patch with a bugfix. This was also fixed in Tokio
1.x-compatible versions of Hyper. There are still users of hyper-02 in fbcode.
However, this is only used for servers and only when accepting websocket
connections, and those users are just using Hyper as a HTTP client.

Reviewed By: farnz

Differential Revision: D28091331

fbshipit-source-id: de13b2452b654be6f3fa829404385e80a85c4420
2021-04-29 08:07:45 -07:00
Thomas Orozco
ffed22260d third-party/rust: remove Gotham 0.2
Summary:
This used to be used by Mononoke, but we're now on Tokio 1.x and on
corresponding versions of Gotham so it's not needed anymore.

Reviewed By: farnz

Differential Revision: D28091091

fbshipit-source-id: a58bcb4ba52f3f5d2eeb77b68ee4055d80fbfce2
2021-04-29 08:07:45 -07:00
Thomas Orozco
0f44a4f106 mononoke: update to tokio 1.x
Summary:
NOTE: there is one final pre-requisite here, which is that we should default all Mononoke binaries to `--use-mysql-client` because the other SQL client implementations will break once this lands. That said, this is probably the right time to start reviewing.

There's a lot going on here, but Tokio updates being what they are, it has to happen as just one diff (though I did try to minimize churn by modernizing a bunch of stuff in earlier diffs).

Here's a detailed list of what is going on:

- I had to add a number `cargo_toml_dir` for binaries in `eden/mononoke/TARGETS`, because we have to use 2 versions of Bytes concurrently at this time, and the two cannot co-exist in the same Cargo workspace.
- Lots of little Tokio changes:
  - Stream abstractions moving to `tokio-stream`
  - `tokio::time::delay_for` became `tokio::time::sleep`
  - `tokio::sync::Sender::send` became `tokio::sync::Sender::broadcast`
  - `tokio::sync::Semaphore::acquire` returns a `Result` now.
  - `tokio::runtime::Runtime::block_on` no longer takes a `&mut self` (just a `&self`).
  - `Notify` grew a few more methods with different semantics. We only use this in tests, I used what seemed logical given the use case.
- Runtime builders have changed quite a bit:
  - My `no_coop` patch is gone in Tokio 1.x, but it has a new `tokio::task::unconstrained` wrapper (also from me), which I included on  `MononokeApi::new`.
  - Tokio now detects your logical CPUs, not physical CPUs, so we no longer need to use `num_cpus::get()` to figure it out.
- Tokio 1.x now uses Bytes 1.x:
  - At the edges (i.e. streams returned to Hyper or emitted by RepoClient), we need to return Bytes 1.x. However, internally we still use Bytes 0.5 in some places (notably: Filestore).
  - In LFS, this means we make a copy. We used to do that a while ago anyway (in the other direction) and it was never a meaningful CPU cost, so I think this is fine.
  - In Mononoke Server it doesn't really matter because that still generates ... Bytes 0.1 anyway so there was a copy before from 0.1 to 0.5 and it's from 0.1 to 1.x.
  - In the very few places where we read stuff using Tokio from the outside world (historical import tools for LFS), we copy.
- tokio-tls changed a lot, they removed all the convenience methods around connecting. This resulted in updates to:
  - How we listen in Mononoke Server & LFS
  - How we connect in hgcli.
  - Note: all this stuff has test coverage.
- The child process API changed a little bit. We used to have a ChildWrapper around the hg sync job to make a Tokio 0.2.x child look more like a Tokio 1.x Child, so now we can just remove this.
- Hyper changed their Websocket upgrade mechanism (you now need the whole `Request` to upgrade, whereas before that you needed just the `Body`, so I changed up our code a little bit in Mononoke's HTTP acceptor to defer splitting up the `Request` into parts until after we know whether we plan to upgrade it.
- I removed the MySQL tests that didn't use mysql client, because we're leaving that behind and don't intend to support it on Tokio 1.x.

Reviewed By: mitrandir77

Differential Revision: D26669620

fbshipit-source-id: acb6aff92e7f70a7a43f32cf758f252f330e60c9
2021-04-28 07:36:31 -07:00