Summary:
Unfortunately the more time I've spent with this the more I've realized how poorly the whole `polars` import in `fbsource` (`third-party/pypi:polars` + `third-party/rust:polars` + `third-party/rust:polars-py`) has been done. To be fair it is quite a complicated use case and definitely the largest dep footprint Rust/Python module in all of `fbsource`. For more context see T179532760 but this is the 1st step of many to fix everything and hopefully move `polars` out of `third-party/rust` completely.
That said, the work here allows me to land `1.76.0` without having to upgrade `pyo3` + `polars` + `libcst` + tons of other crates (stack @ D53776888) and do that with more time on my hands post land.
Reviewed By: dtolnay
Differential Revision: D53858402
fbshipit-source-id: 3644897f2b569ebc23463dd35aba77bd5c59fca6
Summary:
This diff adds the functionality of asking the user if they want to terminate processing preventing eden rm from succeeding.
Also some refactoring done, specifically create prompt.py for the prompt utility because having in cmd_util (which imports config, which imports cmd_util) was causing a circular reference problem when trying to import from file_handler_tools.
Reviewed By: MichaelCuevas
Differential Revision: D53688726
fbshipit-source-id: cf1c6f32ec9e026fa29932554fb552740ad2c5a5
Summary:
# Context
eden rage is a tool used to gather diagnostic output for debugging issues with eden. One of the things it does is collect a variety of logs and sends them to paste.
# This Diff
This diff adds 2 new log sources to eden rage,
1) edenfs_upgrade.log - written by a scheduled python script that restarts EdenFS on a weekly basis to ensure users are running with the most current release
2) edenfs_config.log - written by a scheduled python script that delivers EdenFS configs to user machines
# Technical Details
The logs are read on disk and sent to paste. The link to the paste is displayed in the rage output.
Reviewed By: genevievehelsel
Differential Revision: D53717899
fbshipit-source-id: d18545dfe224e6c4ad37688e75720159f1901400
Summary:
# Context
Purgeable space is an APFS concept where certain types of data is retained when "deleted" to be cleaned up at a later point in time by the OS or manually. Certain workflows lead to the creation of alot of purgeable space. We would like to create a command for users to easily see and clean out this space.
# This Diff
This diff adds the --purgeable flag to `eden du`. This command only works on macOS. When running `eden du` on macOS without the flag, the summary output will hint to the user that the flag exists. When running with the flag, the user will see the space available in purgeable space and ask the user if they want to clear it.
# Technical Details
- --purgeable flag added, should only work on macOS but exists on other platforms for compiler reasons. Has no effect on non-macOS platforms
- When run with the flag performs the following commands
-- Reports Amount of purgeable storage
sudo /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -G $HOME
-- Purges purgeable storage
sudo /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -P -total <value from -G> $HOME
- displays usage space in summary output
- user will be prompted to clear space or not
- user will be asked for sudo passsword
# Discussion Points
1. Text output is open to adjustment
Reviewed By: MichaelCuevas
Differential Revision: D53591104
fbshipit-source-id: 38f4d92d027394bc0d29e4a066ba06ac83f3fc72
Summary:
`-Wextra-semi` or `-Wextra-semi-stmt` found an extra semi
If the code compiles, this is safe to land.
Reviewed By: MichaelCuevas
Differential Revision: D53776196
fbshipit-source-id: f83dda6df32622f1ced24d051eadeaa8ebfda4e8
Summary:
This document is not up to date with the EdenFS Config Manager, and would be nice to reference when getting questions about how everything works.
VSCode formatted the file for me, so some of this diff is just formatting change as well.
Reviewed By: kmancini
Differential Revision: D53589632
fbshipit-source-id: 389c2ee18f71533ca5c7bb4f922a36c63aa431e4
Summary:
This diff moves the code that manages handler.exe to its own module and abstract the functionality into a base class, even though for now only Windows is implemented.
It also calls this new handle in the branch that deletes a non-Eden directory, because it's very convenient to test.
Reviewed By: genevievehelsel
Differential Revision: D53594227
fbshipit-source-id: 309efab3f89893f745a82fe5acd128ecd702d42e
Summary:
Refactored a few things:
- Removed ODS tracking code
- Re-named interfaces to not be SCS specific
- Renamed CASCountersManager to `StorageDemandControl`
Logic wise nothing has changed, so this should be a safe land.
Reviewed By: Skory
Differential Revision:
D53598493
Privacy Context Container: L1141686
fbshipit-source-id: 32d6ba623af134c6de54908b9f09622306c7afd0
Summary:
# Problem
The `eden clone` and `hg clone` command currently allow you to specify that you want to use FilteredFS, but they don't allow you to specify the filter to active after the clone completes. Instead, the user has to manually set the filter themselves by running `hg filteredfs enable {path_to_filter}`.
This is annoying for many reasons, and it prevents us from easily rolling out filters on Sandcastle/ODs.
# Solution
We should allow users to pass in the Filter they want to enable at clone time. This will allow them to skip the `hg filteredfs enable {path_to_filter}` step. Even better, we'll allow passing this filter via an Hg Config. That way we can easily enable FilteredFS + use a specific filter just by setting a config value.
# This diff
Adds the option to pass a --filter-path to `eden clone`. This will be used in the next diff to allow passing the filter path via config to `hg clone`.
Reviewed By: genevievehelsel
Differential Revision: D53599526
fbshipit-source-id: 1e5d8e8f7e66157f345d49ff51a36b977b19b96d
Summary:
# Problem
The `eden clone` and `hg clone` command currently allow you to specify that you want to use FilteredFS, but they don't allow you to specify the filter to active after the clone completes. Instead, the user has to manually set the filter themselves by running `hg filteredfs enable {path_to_filter}`.
This is annoying for many reasons, and it prevents us from easily rolling out filters on Sandcastle/ODs.
# Solution
We should allow users to pass in the Filter they want to enable at clone time. This will allow them to skip the `hg filteredfs enable {path_to_filter}` step. Even better, we'll allow passing this filter via an Hg Config. That way we can easily enable FilteredFS + use a specific filter just by setting a config value.
# This diff
All of these should take an optional filter_path argument. This will be used by clone to set the active filter at clone time.
Reviewed By: jdelliot
Differential Revision: D53599527
fbshipit-source-id: c6573cd4886620a21471101e5cc2151e815de7f1
Summary:
# Problem
The `eden clone` and `hg clone` command currently allow you to specify that you want to use FilteredFS, but they don't allow you to specify the filter to active after the clone completes. Instead, the user has to manually set the filter themselves by running `hg filteredfs enable {path_to_filter}`.
This is annoying for many reasons, and it prevents us from easily rolling out filters on Sandcastle/ODs.
# Solution
We should allow users to pass in the Filter they want to enable at clone time. This will allow them to skip the `hg filteredfs enable {path_to_filter}` step. Even better, we'll allow passing this filter via an Hg Config. That way we can easily enable FilteredFS + use a specific filter just by setting a config value.
# This diff
Instead of making the caller create the FilterID themselves, have them pass in a filter path which will be used to create the FilterID. This will be used in the next diff since clone will now take a --filter-path argument.
Reviewed By: jdelliot
Differential Revision: D53599529
fbshipit-source-id: 3d200b817e9928180a8cfd319f39188bd41dae8f
Summary: We will log the occurrences for now so we can track how often this occurs.
Reviewed By: kmancini
Differential Revision: D53595535
fbshipit-source-id: acaf331d9eb6ed297eafd174c8141b066422f478
Summary:
# Context
The "eden du" command displays the actual storage used on disk. This is used when users want to know how much actual storage is being used by eden for purposes such as clearing up disk space.
# This Diff
This diff migrates the thrift endpoint from getScmStatus to getScmStatusV2
# Technical Details
getScmStatusV2 packages the previous values of getScmStatus into a substruct and adds some new field. This diff moves the previous values of getScmStatus into that substruct and uses default values for the fields not previously present.
Reviewed By: MichaelCuevas
Differential Revision: D53581822
fbshipit-source-id: 7fcb756d5096a2a0a53075870bae979a301f0e87
Summary:
The first time handle.exe is called is shows a popup asking the user to accept the EULA.
Passing the argument -eulaaccepted bypasses this popup.
Reviewed By: MichaelCuevas
Differential Revision: D53589443
fbshipit-source-id: 2cdb56c157a297f3107b822982074a89817335d2
Summary:
During my first test of rm I saw that if rm is passed a file (that exists) instead of a directory the message is unclear (correct, but not obvious if you don't realize you passed the wrong thing).
I think just reporting that it's a file and not a directory and still allowing to delete it is a bit better.
Reviewed By: MichaelCuevas
Differential Revision: D53551256
fbshipit-source-id: 1ec367267d53185dec5ddac69d44039e39ea743c
Summary:
# Context
The "eden du" command displays the actual storage used on disk. This is used when users want to know how much actual storage is being used by eden for purposes such as clearing up disk space.
# This Diff
This diff adds a new details section to the output that displays the individual storage usage of each redirect. This lets them
Old:
```
Summary
-------
Materialized files: 311.2 MB
Redirections: 29.9 GB
Ignored files: 1.3 MB
Backing repos: 46.0 MB
Shared space: 254.7 MB
```
New:
```
Summary
-------
Materialized files: 311.3 MB
Redirections: 29.9 GB
Ignored files: 1.3 MB
Backing repos: 49.6 MB
Shared space: 254.7 MB
Details
-------
29.9 GB: buck-out
0: fbcode/buck-out
0: fbcode/.cpplsp-buck-out
0: .pylsp-buck-out
```
# Technical Details
The detail output is formatted as
```
Storage : local path
```
Storage is sorted by size descending.
I chose to have the path after the size due to variable length pathnames making it difficult to easily compare the storage being used
# Discussion Points
1. Should folders of size 0 be listed as 0 B
2. Other folder listings are displayed as fullpaths eg.
```
Buck redirections
-----------------
/data/users/cqd/fbsource/buck-out
/data/users/cqd/fbsource/fbcode/buck-out
```
should detail also display the fullpath, eg as
```
Details
-------
29.9 GB: /data/users/cqd/fbsource/buck-out
0: /data/users/cqd/fbsource/fbcode/buck-out
0: /data/users/cqd/fbsource/fbcode/.cpplsp-buck-out
0: /data/users/cqd/fbsource/.pylsp-buck-out
```
Reviewed By: MichaelCuevas
Differential Revision: D53290943
fbshipit-source-id: 20f5e1ce32131130c2f6a9ff5bb8f8bd7a46e482
Summary:
The DC for storage should all sit in the same place, i.e.
remote_execution/cas/capacity. This fixes it.
Differential Revision:
D53535912
Privacy Context Container: L1141686
fbshipit-source-id: e9383c2513ae731918ac37e95b7a4acf183d8145
Summary:
Our upcoming compiler upgrade will require us not to have shadowed variables. Such variables have a _high_ bug rate and reduce readability, so we would like to avoid them even if the compiler was not forcing us to do so.
This codemod attempts to fix an instance of a shadowed variable. Please review with care: if it's failed the result will be a silent bug.
**What's a shadowed variable?**
Shadowed variables are variables in an inner scope with the same name as another variable in an outer scope. Having the same name for both variables might be semantically correct, but it can make the code confusing to read! It can also hide subtle bugs.
This diff fixes such an issue by renaming the variable.
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: palmje
Differential Revision: D53478938
fbshipit-source-id: 686af60cacd2c6d356f2ad6464b51712b59ed96f
Summary:
Our upcoming compiler upgrade will require us not to have shadowed variables. Such variables have a _high_ bug rate and reduce readability, so we would like to avoid them even if the compiler was not forcing us to do so.
This codemod attempts to fix an instance of a shadowed variable. Please review with care: if it's failed the result will be a silent bug.
**What's a shadowed variable?**
Shadowed variables are variables in an inner scope with the same name as another variable in an outer scope. Having the same name for both variables might be semantically correct, but it can make the code confusing to read! It can also hide subtle bugs.
This diff fixes such an issue by renaming the variable.
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: palmje
Differential Revision: D53478924
fbshipit-source-id: 619cd5814bdc1804edb6366e381f26bfe75bb56d
Summary:
Our upcoming compiler upgrade will require us not to have shadowed variables. Such variables have a _high_ bug rate and reduce readability, so we would like to avoid them even if the compiler was not forcing us to do so.
This codemod attempts to fix an instance of a shadowed variable. Please review with care: if it's failed the result will be a silent bug.
**What's a shadowed variable?**
Shadowed variables are variables in an inner scope with the same name as another variable in an outer scope. Having the same name for both variables might be semantically correct, but it can make the code confusing to read! It can also hide subtle bugs.
This diff fixes such an issue by renaming the variable.
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: palmje
Differential Revision: D53478940
fbshipit-source-id: da0e0a0043f87fa27599ec051c3c772eba0721d4
Summary:
Our upcoming compiler upgrade will require us not to have shadowed variables. Such variables have a _high_ bug rate and reduce readability, so we would like to avoid them even if the compiler was not forcing us to do so.
This codemod attempts to fix an instance of a shadowed variable. Please review with care: if it's failed the result will be a silent bug.
**What's a shadowed variable?**
Shadowed variables are variables in an inner scope with the same name as another variable in an outer scope. Having the same name for both variables might be semantically correct, but it can make the code confusing to read! It can also hide subtle bugs.
This diff fixes such an issue by renaming the variable.
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: palmje
Differential Revision: D53451014
fbshipit-source-id: aec2e35fa3b105380c6d4115543bf753ceb259ea
Summary:
Our upcoming compiler upgrade will require us not to have shadowed variables. Such variables have a _high_ bug rate and reduce readability, so we would like to avoid them even if the compiler was not forcing us to do so.
This codemod attempts to fix an instance of a shadowed variable. Please review with care: if it's failed the result will be a silent bug.
**What's a shadowed variable?**
Shadowed variables are variables in an inner scope with the same name as another variable in an outer scope. Having the same name for both variables might be semantically correct, but it can make the code confusing to read! It can also hide subtle bugs.
This diff fixes such an issue by renaming the variable.
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: palmje
Differential Revision: D53451028
fbshipit-source-id: fb39814f7e9a79349f7d780d835ac3b6476bf9a9
Summary: StringKeyedUnorderedMap is a shim whose purpose is to provide F14Map. Just use the latter.
Reviewed By: genevievehelsel
Differential Revision: D53376952
fbshipit-source-id: c61ef2fdfe611ef9adb5ffefcc72b286e5ef093d
Summary:
Changes resulting from {D53374511}. I think this was supposed to be in that diff.
It doesn't necessarily make sense to have these fbcode target names in Autocargo-generated code that gets shipped to GitHub. I can look into getting autocargo to omit these.
Reviewed By: zertosh, shayne-fletcher
Differential Revision: D53379521
fbshipit-source-id: 6377e6181b0b1e0a86f6144e208773959fda0ac0
Summary:
I came across this failure in `oss-mononoke-linux-getdeps` likely caused by {D53302058}:
> error: document output filename collision
> The lib `bonsai_globalrev_mapping_thrift` in package `bonsai_globalrev_mapping_thrift_types v0.1.0 (/data/sandcastle/temp/skycastle/fbcode_builder_getdeps/build/mononoke/source/eden/mononoke/bonsai_globalrev_mapping/if/types)` has the same name as the lib `bonsai_globalrev_mapping_thrift` in package `bonsai_globalrev_mapping_thrift v0.1.0 (/data/sandcastle/temp/skycastle/fbcode_builder_getdeps/build/mononoke/source/eden/mononoke/bonsai_globalrev_mapping/if)`.
> Only one may be documented at once since they output to the same path.
> Consider documenting only one, renaming one, or marking one with `doc = false` in Cargo.toml.
We don't need Cargo-generated docs of Thrift targets.
Reviewed By: zertosh
Differential Revision: D53339579
fbshipit-source-id: 3dc0d404777ca436e0f6de7ae7491925d709e331
Summary: Users will get the best results if they pass in `~/*` as the path argument for the apfs.util command.
Reviewed By: genevievehelsel
Differential Revision: D53326600
fbshipit-source-id: 521dcf05cae001747beaa3f117d215b33a7895db
Summary:
The Rust Thrift implementation presently compiles to 4 crates:
```lang=mermaid
flowchart TD;
foo --> foo-clients;
foo --> foo-types;
foo --> foo-services;
foo-clients --> foo-types;
foo-services --> foo-types;
```
Sadly, the one with the best name is the most useless. That top-level foo crate just contains the following:
```
pub use ::foo_types as types;
pub use ::foo_clients as client;
pub use ::foo_services as server;
pub use ::foo_types::consts;
pub use ::foo_types::errors;
pub use ::foo_types::services;
pub use ::foo_clients::mock;
pub use self::consts::*;
pub use self::errors::*;
pub use self::types::*;
```
Furthermore, it is extremely uncommon for anything to want to be both a client and a server of the *same* Thrift interface. It arises occasionally for proxies, but otherwise you are either implementing the server for a particular service, or accessing it as a client, not both.
I am interested in eliminating the useless crate, and renaming the types subcrate to the nice name.
```lang=mermaid
flowchart TD;
foo-clients --> foo;
foo-services --> foo;
```
### Implementation plan
1. This diff
2. Migrate everything that uses `:foo-rust` and needs a client to `:foo-rust-clients`, and everything that needs a server to `:foo-rust-services` -- after this point, everything still depending on `:foo-rust` only uses types
3. In the macros, atomically delete `:foo-rust` and rename `:foo-rust-types` into its place (this will be a small diff)
Reviewed By: zertosh, shayne-fletcher
Differential Revision: D53302058
fbshipit-source-id: 8d28c90f3a13e71e0cedd3ce3c1cb6fe40cffe27
Summary:
# Before:
If a Thrift library A depends on Thrift library B, all of the dependencies on B are bottlenecked through B's main library. That means building A's clients requires building B's servers, and building A's servers requires building B's clients, neither of which should be necessary.
```lang=mermaid
flowchart TD;
A --> A-clients;
A --> A-types;
A --> A-services;
A-clients --> A-types;
A-services --> A-types;
B --> B-clients;
B --> B-types;
B --> B-services;
B-clients --> B-types;
B-services --> B-types;
A --> B;
A-clients --> B;
A-services --> B;
A-types --> B;
```
# After:
A tidy lattice. Projects that implement a Thrift service can build only the servers for A and B, without also building all their clients. Projects that need Thrift clients for various services can build just the clients without also building a bunch of unused infrastructure for writing a server implementation.
```lang=mermaid
flowchart TD;
A --> A-clients;
A --> A-types;
A --> A-services;
A-clients --> A-types;
A-services --> A-types;
B --> B-clients;
B --> B-types;
B --> B-services;
B-clients --> B-types;
B-services --> B-types;
A --> B;
A-clients --> B-clients;
A-services --> B-services;
A-types --> B-types;
```
Reviewed By: shayne-fletcher
Differential Revision: D53246158
fbshipit-source-id: 37cc5cb111c39c567c69e8fb2eaf23fd940082b3
Summary: `folly::StringKeyedUnorderedMap` used to be a complicated class, but is now a simple typedef to `F14NodeMap<std::string, Mapped>`. Just use the latter.
Reviewed By: bcardosolopes, xavierd
Differential Revision: D53232021
fbshipit-source-id: 4b545d1c912dae2bbf89e31354f831d818c85167
Summary:
They still haven't released 0.5.0, but made some improvements on the path
there. This brings us back to their newest commit
To keep backwards compatibility (and fix the tests that break because of broken bc), this needs to be landed together with D53111463.
Reviewed By: dtolnay
Differential Revision: D53074256
fbshipit-source-id: 124badef3c923acda758e75f1a4437d8826d5f7c
Summary:
Update libbpf-sys to version 1.3.0+v1.3.0. This release includes libbpf in
version v1.3.0, which is what we were waiting on. Because this release contains
some incompatibilities, we also have to update libbpf-rs to the most recent
snapshot. A new libbpf-rs release will come once sufficient features have
accumulated.
Reviewed By: shayne-fletcher
Differential Revision: D53102023
fbshipit-source-id: 47b74d38b04237d4d5ba1f93fe19e83b9d2b6125
Summary:
## Problem
Having an "automatic remediation" for full storage is misleading:
1) Our remediation may not actually solve the full disk space issue
2) Our remediation doesn't actually work since the `apfs.util` command we run requires `sudo` to correctly purge all purgeable space.
## Solution
Instead of claiming that we automatically remediated the issue, let's inform the user of the potential problem, tell them how they can check if that's the *actual* problem, and then give them a remediation they can run to fix the problem. While this is strictly worse than automatically running the remediation for them, it's much better than running a remediation that doesn't actually work and claiming it fixed the problem.
Reviewed By: genevievehelsel
Differential Revision: D53200901
fbshipit-source-id: 23dc142b4c0d236d8b31bba85d0a8f98fe76aeba
Summary:
# Summary:
Keeping a vector of config options, manually deserializing/serializing them, and then using string-comparisions to check the type seems like a bad long-term trend. Let's move towards using enums for these types of things (like I introduced in D53146609).
# Solution:
This diff enum-izes (enum-erizes) the InodeCatalogType that we parse from the CheckoutConfigs.
Reviewed By: jdelliot
Differential Revision: D53151826
fbshipit-source-id: b646f92f5a308a46d37d43758535cc5dfdd58164
Summary: See title. I liked this message better than the old one.
Reviewed By: jdelliot
Differential Revision: D53151834
fbshipit-source-id: 05dad98d79572972675653ec873f497ae8ab9ee3
Summary:
# Summary:
Keeping a vector of config options, manually deserializing/serializing them, and then using string-comparisions to check the type seems like a bad long-term trend. Let's move towards using enums for these types of things (like I introduced in D53146609).
# Solution:
This diff enum-izes (enum-erizes) the MountProtocols that we parse from the CheckoutConfigs.
Reviewed By: jdelliot
Differential Revision: D53151833
fbshipit-source-id: b2e71e6a8ba451fcf46e7d2119b6be3b3ce0f4c4
Summary:
# Problem:
FilteredFS repos write FilteredRootIds to the Snapshot file so that they can track the current working copy parent, active FilterID, and parse those two pieces of information as needed.
This means that the current getSnapshot logic naively returns FilteredRootIds instead of the expected commit hashes as expected.
# Solution:
We can modify getSnapshot to properly parse the FilteredRootIds and return only the commit hash to the caller.
Reviewed By: jdelliot
Differential Revision: D53146665
fbshipit-source-id: c38980f00b977f525fba654e146e88f8e1693c43
Summary:
# Problem:
The next diff implements correct getSnapshot() logic which requires doing a comparison of the repo_type config field. Instead of comparing raw strings, we should compare enums.
# Solution:
We can parse the repo_type CheckoutConfig option as an enum to avoid string comparison for determining repo types.
This requires implementing to/from string implementations for the new RepositoryType enum. We can use the strum crate to do this for us.
We can then use the to/from string implementations to deserialize (and serialize) CheckoutConfigs.
Reviewed By: kmancini
Differential Revision: D53146609
fbshipit-source-id: 29cc702695381021b210f85f83855b84dc11534e
Summary:
I discovered a case where `eden du` passes in a FilteredFS commit hash into getScmStatus (v1). This causes `eden du` to crash.
This bug stems from the Rust version of get_snapshot() not parsing out the filter information for FilteredFS Snapshot files: https://www.internalfb.com/code/fbsource/[8496d7622d579ebf9253522ec56b35a1353c25ad]/fbcode/eden/fs/cli_rs/edenfs-client/src/checkout.rs?lines=557-612
We correctly parse out the Filter info in the Python CLI (since we have varint utils implemented), but we don't in the Rust CLI because we don't have varint encode/decode functions available.
This diff adds the utils to the Rust CLI so I can correctly parse out filter info and fix `eden du`
Reviewed By: kmancini
Differential Revision: D52928980
fbshipit-source-id: 3258acacde639adaf66e53e0c49578fbb0b1e782
Summary:
X-link: https://github.com/facebookincubator/velox/pull/8558
The attribute `[[fallthrough]]` is standard C++17. We no longer need to wrap it.
Reviewed By: Orvid
Differential Revision: D53034074
fbshipit-source-id: 19b1e8314e70f3e08882e76b93f7ded4df7ab9f2
Summary: Use the commit with the fix while we wait for a new release.
Differential Revision: D53127691
fbshipit-source-id: 6128ea1ffe00d7e8d8081d7ea5093e8bb813c04f
Summary:
make it possible to call `shlex::try_join` and remove the temporary `#[allow(deprecated)]` from buck2_wrapper_common.
buck2/Cargo.toml is restored to the state it had in b9dddef8e77c334a30071810e4ef851e8ad945bb before the workaround applied in D53087714 (which implies at this time shlex-1.3.0).
Reviewed By: ndmitchell, samkevich
Differential Revision: D53001954
fbshipit-source-id: 4267b80b5884b1a1e75c938af641e3f2656bf9a7
