Part 1 of RFC2906 - Packages can inherit fields from their root workspace #10497

Muscraft · 2022-03-22T02:44:02Z

Tracking issue: #8415
RFC: rust-lang/rfcs#2906

All changes were heavily inspired by #8664 and #9684

A big thanks to both @yaymukund and @ParkMyCar. I pulled a lot of inspiration from their branches.

I would also like to thank @alexcrichton for all the feedback on the first attempt. It has brought this into a much better state.

All changes have been made according to the RFC as well as @alexcrichton's comment.

This is part 1 of many, as described by this comment, this comment and redefined by this one.

This PR focuses on inheriting in root package, including:

Add MaybeWorkspace<T> to allow for { workspace = true }
Add a new variant to TomlDependency to allow inheriting dependencies from a workspace
Add InheritableFields so that we have somewhere to get a value from when we resolve a MaybeWorkspace<T>
- license_file and readme are in InheritableFields in this part but are not MaybeWorkspace for reasons described here
Add a method to resolve a MaybeWorkspace<T> into a T that can fail if we have nowhere to pull from or the workspace does not define that field
Disallow inheriting from a different Cargo.toml
- This means that you can only inherit from inside the same Cargo.toml, i.e. it has both a [workspace] and a [package]
- Forcing this requirement allows us to test the implementations of MaybeWorkspace<T> and the new TomlDependency variant without having to add searching for a workspace root and the complexity with it

Remaining implementation work for the RFC

Support inheriting in any workspace member
Correctly inherit fields that are relative paths
- Including adding support for inheriting license_file, readme, and path-dependencies
Path dependencies infer version directive
Lock workspace dependencies and warn when unused
Optimizations, as needed
Evaluate any new fields for being inheritable (e.g. rust-version)
Evaluate making users of { workspace = true } define the workspace they pull from in [package]

Areas of concern:

TomlDependency Deserialization is a mess, and I could not figure out how to do it in a cleaner way without significant headaches. I ended up having to do the same thing as last time which was an issue.
Resolving on a MaybeWorkspace feels extremely verbose currently:
```
project.homepage.clone().map(|mw| mw.resolve(&features, "homepage", || get_ws(inheritable)?.homepage())).transpose()?,
```
This way allows for lazy resolution of inheritable fields and finding a workspace (in part 2) so you do not pay a penalty for not using this feature. The other bit of good news is &features will go away as it is just feature checking currently.
This feature requires some level of duplication of code as well as remaking the original TomlManifest which adds extra length to the changes.
This feature also takes a linear process and makes it potentially non-linear which adds lots of complexity (which will get worse in Part 2)

Please let me know if you have any feedback or suggestions!

rust-highfive · 2022-03-22T02:44:06Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon.

Please see the contribution instructions for more information.

epage · 2022-03-22T19:38:56Z

This is part 1 of 2 - 3 as described by #9684 (comment) as well as #9684 (review).

As a heads up the "miscellaneous" aspect of part 3 is about to grow. cargo add is in FCP, see #10472.

I think it could make sense to break this out into a step 4. I could help out of implement that part. I've recorded more details on the tracking issue.

epage

Thanks for doing this! I'm very excited by this feature!

I'm taking a break for now; all I have left are the tests.

Could you be more explicit in what the parts are? I might have missed it but looking at the past comments, I'm not seeing "Path dependencies infer version directive" mentioned and wanting to make sure that we are taking that into account for closing out the RFC.

src/cargo/util/toml/mod.rs

Muscraft · 2022-03-23T04:36:59Z

Could you be more explicit in what the parts are? I might have missed it but looking at the past comments, I'm not seeing "Path dependencies infer version directive" mentioned and wanting to make sure that we are taking that into account for closing out the RFC.

I edited my original comment/explanation to better explain what is happening in each part. Let me know if I need to change anything or make the parts clearer,

epage · 2022-03-23T12:06:51Z

I edited my original comment/explanation to better explain what is happening in each part. Let me know if I need to change anything or make the parts clearer,

Thanks! Its helpful when reviewing to have the full context of what is expected to be in scope and out of scope so I know what to look for.

I'm thinking it would be good to break up Part 2 to be more focused so the review process is easier for everyone.

My suggestion for different PRs

Support for inheriting in root package (this PR)
Support inheriting in any workspace member
Correctly inherit fields that are relative paths
- I could see delaying support for inheriting these fields until this PR but I can go either way
Path dependencies infer version directive
Optimizations, as needed (PR per optimization)

These are

User-facing / testable
Narrow scoped
Single purpose
Mostly parallizable

When PRs try to fulfill too many purposes

It can be unclear which purpose a changed line is helping, requiring more time from the reviewer
Things are more likely to be missed in each pass but then found in a later one, leading to a lot of back-and-forth which can be frustrating and discouraging for everyone
A single point of concern can hold up every improvement
The longer and more iterations a PR goes through, the more conflicts that will have to be handled by the author.

Muscraft · 2022-03-23T15:00:41Z

My suggestion for different PRs

Support for inheriting in root package (this PR)

Support inheriting in any workspace member

Correctly inherit fields that are relative paths

I could see delaying support for inheriting these fields until this PR but I can go either way

Path dependencies infer version directive

Optimizations, as needed (PR per optimization)

Support inheriting in any workspace member, and Correctly inherit fields that are relative paths to me are fairly tied together since this would delay license-file, readme, and dependencies (I think this is all that could be relative paths) until part 3. It would require setting up tests in Part 2 to disallow these things and error messages and testing for them could be a bit odd.

If we were to split these into Part 2 and Part 3, I think Part 1 should remove MaybeWorkspace<T> from license-file and readme and only add them back in Part 3. We can leave dependencies the same as we have now since its resolve is separate and could be updated in Part 3/4.

I'm flexible on how we want to go about this and will happily do whatever is easiest to review.

epage · 2022-03-23T15:07:08Z

If we were to split these into Part 2 and Part 3, I think Part 1 should remove MaybeWorkspace from license-file and readme and only add them back in Part 3. We can leave dependencies the same as we have now since its resolve is separate and could be updated in Part 3/4.

As I said, I'm fine with it if you want to remove them from this PR.

I'm flexible on how we want to go about this and will happily do whatever is easiest to review.

Let's move forward with this then so this has the best chances of making it in!

-- `resolve` not takes `get_ws: impl FnOnce() -> CargoResult<T>` -- removed `MaybeWorkspace` from `readme` and `license-file` -- changed error messages and test names

Muscraft · 2022-03-23T18:50:03Z

Let me know your thoughts on the newest commit, I believe I made all the changes you had mentioned so far.

Changing to a impl FnOnce() -> CargoResult<T> did have some benefits and made things less cluttered overall, but it made the getters for InheritableFields a little verbose. If the getters need to be fixed, we could do a macro_rules! but I dislike this for readability and maintenance reasons. If you have any suggestions I think it might be a pain point.

What are your thoughts on adding rust_version as mentioned here? Personally, I think we could add it if not, adding it to a part down the line is perfectly fine as well. It also could be added with a separate PR not part of this RFC since it was not mentioned in the RFC.

I will update what is being done in the parts in the main part of my PR so others can see what is going on easier.

src/cargo/core/workspace.rs

src/cargo/util/toml/mod.rs

epage · 2022-03-23T19:12:16Z

Changing to a impl FnOnce() -> CargoResult<T> did have some benefits and made things less cluttered overall, but it made the getters for InheritableFields a little verbose. If the getters need to be fixed, we could do a macro_rules! but I dislike this for readability and maintenance reasons. If you have any suggestions I think it might be a pain point.

I think it looks great. Putting it on the inheritable fields helps keep all the error reporting in one place so we can keep them in sync.

What are your thoughts on adding rust_version as mentioned here? Personally, I think we could add it if not, adding it to a part down the line is perfectly fine as well. It also could be added with a separate PR not part of this RFC since it was not mentioned in the RFC.

I think this is a wider conversation that should be addressed independent of this PR. I've gone ahead and updated the tracking issue with a check box for this.

epage

Finally got to looking at the tests

tests/testsuite/deduplicate_workspace.rs

epage · 2022-03-23T19:50:50Z

@Muscraft I hope you don't mind, I made some edits to the PR description to try make the intent clearer to bring others on board more quickly as I share this.

I also updated the relative path handling to include path-dependencies on top of readme and license_file, see https://github.com/rust-lang/rfcs/blob/master/text/2906-cargo-workspace-deduplicate.md#effect-resolution-for-relative-path-dependencies

Looking over the RFC, a couple more items I've noticed that we don't have covered

Should we have a test to verify cargo metadata and cargo read-manifests behavior?
Looks like we should add to our task list the Cargo.lock handling as I don't think I saw it in this PR

Muscraft · 2022-03-23T20:36:51Z

Looking over the RFC, a couple more items I've noticed that we don't have covered

Should we have a test to verify cargo metadata and cargo read-manifests behavior?

Looks like we should add to our task list the Cargo.lock handling as I don't think I saw it in this PR

Would these not be covered by other tests in cargo? or are you meaning explicit tests that have { workspace = true }? For the most part, I think that these two things shouldn't be an issue since as we resolve things we overwrite the original TomlManifest with the resolved values. Cargo.lock showing warnings for unused dependencies is the only thing I could see going on but I'm not sure how to test for that or metadata.

Changing to a impl FnOnce() -> CargoResult did have some benefits and made things less cluttered overall, but it made the getters for InheritableFields a little verbose. If the getters need to be fixed, we could do a macro_rules! but I dislike this for readability and maintenance reasons. If you have any suggestions I think it might be a pain point.

I think it looks great. Putting it on the inheritable fields helps keep all the error reporting in one place so we can keep them in sync.

The only way I think we could keep them more in sync would be to make a function in InheritbaleFields to handle the error message. Something like

fn error(&self, field: &str) -> anyhow::Error {
    anyhow!("`workspace.{}` was not defined", field)
}

then each getter would be similar to:

pub fn dependencies(&self) -> CargoResult<BTreeMap<String, TomlDependency>> {
    self.dependencies.clone().map_or(
        Err(self.error("dependencies")),
        |d| Ok(d),
    )
}

This is nitpicky and doesn't have to be done. The real thing would be to get rid of the very similar

map_or(Err(anyhow!("message")), |i|  Ok(i)))

I tried to get rid of this but I made things a bit odd in my brief attempt.

epage · 2022-03-23T20:47:29Z

Would these not be covered by other tests in cargo? or are you meaning explicit tests that have { workspace = true }? For the most part, I think that these two things shouldn't be an issue since as we resolve things we overwrite the original TomlManifest with the resolved values. Cargo.lock showing warnings for unused dependencies is the only thing I could see going on but I'm not sure how to test for that or metadata.

Yes, I was thinking of when they are using {workspace = true}. I would lean towards explicitly having test to make sure our user-facing requirements are tested and will ensure they stay tested through refactors but we can also see what others from the cargo team say.

The only way I think we could keep them more in sync would be to make a function in InheritbaleFields to handle the error message. Something like

If consolidating the error message makes the code worse, I'm personally fine having it in each function. Having them all in one tight location where its obvious that you should update others when updating one is a big help!

Muscraft · 2022-03-23T20:59:53Z

Yes, I was thinking of when they are using {workspace = true}. I would lean towards explicitly having test to make sure our user-facing requirements are tested and will ensure they stay tested through refactors but we can also see what others from the cargo team say.

Sounds good, I saw you added it to the RFC so I will add the tests for it then.

-- removed `[]` from error messages in favor of back-ticks

epage

Thanks for all the work on this!

Muscraft · 2022-03-23T22:25:18Z

Thanks for all the work on this!

Anytime! It's been something I've been meaning to work on for a while and got time to do so. I will start work on Part 2 once this gets merged but it may take me a bit to get reacclimated with what I need to do.

epage · 2022-03-25T01:16:59Z

Going ahead with it as its feature gated, well tested, and should have minimal impact for existing users.

@bors r+

bors · 2022-03-25T01:17:01Z

📌 Commit e6992d4 has been approved by epage

Update cargo 13 commits in 109bfbd055325ef87a6e7f63d67da7e838f8300b..1ef1e0a12723ce9548d7da2b63119de9002bead8 2022-03-17 21:43:09 +0000 to 2022-03-31 00:17:18 +0000 - Support `-Zmultitarget` in cargo config (rust-lang/cargo#10473) - doc: Fix document url for libcurl format (rust-lang/cargo#10515) - Fix wrong info in "Environment variables" docs (rust-lang/cargo#10513) - Use the correct flag in --locked --offline error message (rust-lang/cargo#10512) - Don't treat host/target duplicates as duplicates (rust-lang/cargo#10466) - Unstable --keep-going flag (rust-lang/cargo#10383) - Part 1 of RFC2906 - Packages can inherit fields from their root workspace (rust-lang/cargo#10497) - Remove unused profile support for -Zpanic-abort-tests (rust-lang/cargo#10495) - HTTP registry implementation (rust-lang/cargo#10470) - Add a notice about review capacity. (rust-lang/cargo#10501) - Add tests for ignoring symlinks (rust-lang/cargo#10047) - Update doc string for deps_of/compute_deps. (rust-lang/cargo#10494) - Consistently use crate::display_error on errors during drain (rust-lang/cargo#10394)

Part 2 of RFC2906 -- allow inheriting from a different `Cargo.toml` Tracking issue: #8415 RFC: rust-lang/rfcs#2906 [Part 1](#10497) This PR focuses on inheriting from a root workspace: - Allow inheriting from a different `Cargo.toml` - Add in searching for a workspace root in `to_real_manifest` as needed - Fixed problem where a package would try to pull a dependency from a workspace and specify `{ workspace = true, optional = true }` and it would not respect the `optional` - Added tests to verify everything is in working order Remaining implementation work for the RFC - Correctly inherit fields that are relative paths - Including adding support for inheriting `license_file`, `readme`, and path-dependencies - Path dependencies infer version directive - Lock workspace dependencies and warn when unused - Optimizations, as needed - Evaluate any new fields for being inheritable (e.g. `rust-version`) Problems: - There is duplication of code that can't be removed without significant refactoring - Potential to parse the same manifest many times when searching for a root - This should not happen when a `[package]` specifies its workspace - This should only happen if the workspace root is greater than one folder above

Part 3 of RFC2906 - Add support for inheriting `license-path`, and `depednency.path` Tracking issue: #8415 RFC: rust-lang/rfcs#2906 [Part 1](#10497) [Part 2](#10517) This PR focuses on adding support for inheriting `license-path`, and `depednency.path`: - To adjust the relative paths from being workspace-relative to package-relative, we use `pathdiff` which `cargo-add` is also going to be using for a similar purpose - `ws_path` was added to `InheritableFields` so we can resolve relative paths from workspace-relative to package-relative - Moved `resolve` for toml dependencies from `TomlDependency::<P>` to `TomlDependency` - This was done since resolving a relative path should be a string - You should never inherit from a `.cargo/config.toml` which is the reason `P` was added Remaining implementation work for the RFC - Relative paths for `readme` - Path dependencies infer version directive - Lock workspace dependencies and warn when unused - Optimizations, as needed - Evaluate any new fields for being inheritable (e.g. `rust-version`)

Part 4 of RFC2906 - Add support for inheriting `readme` Tracking issue: #8415 RFC: rust-lang/rfcs#2906 [Part 1](#10497) [Part 2](#10517) [Part 3](#10538) This PR focuses on adding support for inheriting `readme`: - Added adjusting of a `readme` path when it is outside of the `package_root` - Copied from `license-file`'s implementation in `toml::prepare_for_publish()` - Added copying of a `readme` file when it is outside of the `package_root` for publishing - Copied from `license-file`'s implementation in `cargo_package::build_ar_list()` - Merged copying of a file outside of a `package_root` to reduce duplicated code and allow for other files in the future to be copied in a similar way Remaining implementation work for the RFC - Path dependencies infer version directive - Lock workspace dependencies and warn when unused - Optimizations, as needed - Evaluate any new fields for being inheritable (e.g. `rust-version`)

Part 5 of RFC2906 - Add support for inheriting `rust-version` Tracking issue: #8415 RFC: rust-lang/rfcs#2906 Part 1: #10497 Part 2: #10517 Part 3: #10538 Part 4: #10548 This PR focuses on adding support for inheriting `rust-version`. While this was not in the original RFC it was decided that it should be added per [epage's comment](#8415 (comment)). - Changed `rust-version` to `Option<MaybeWorkspace<String>>` in `TomlProject` - Added `rust-version` to `TomlWorkspace` to allow for inheritance - Added `rust-version` to `InheritableFields1 and a method to get it as needed - Updated tests to include `rust-version` Remaining implementation work for the RFC - Switch the inheritance source from `workspace` to `workspace.package`, see [epage's comment](#8415 (comment)) - Add `include` and `exclude` now that `workspace.package` is done, see [epage's comment](#8415 (comment)) - `cargo-add` support, see [epage's comment](#8415 (comment)) - Optimizations, as needed

Part 6 of RFC2906 - Switch the inheritance source from `workspace` to… Tracking issue: #8415 RFC: rust-lang/rfcs#2906 Part 1: #10497 Part 2: #10517 Part 3: #10538 Part 4: #10548 Part 5: #10563 This PR focuses on switching the inheritance source from `workspace` to `workspace.package`. The RFC specified `workspace` but it was decided that it should be changed to `workspace.package` per [epage's comment](#8415 (comment)). - Moved fields that can be inherited to ` package: Option<InheritableFields>` in `TomlWorkspace` - Making `package` `Option<InheritableFields>` was done to remove duplication of types and better signify what fields you can inherit from in one place - Added `#[serde(skip)]` to `ws_root` and `dependencies` in `InheritableFields` since they will never be present when deserializing and we don't want them present when serializing - Added a method to update `ws_root` and `dependencies` in `InheritableFields` - Added for `ws_root` since it will never be present in a `Cargo.toml` and is needed to resolve relative paths - Added for `dependencies` since they are under `workspace.dependencies` not `workspace.package.dependencies` - `workspace.dependencies` was left out of `workspace.package` to better match `package` and `package.dependencies` - Updated error messages from `workspace._` to `workspace.package._` - Updated `unstable.md` to reflect change to `workspace.package` - Updated tests to use `workspace.package` Remaining implementation work for the RFC - Add `include` and `exclude` now that `workspace.package` is done, see [epage's comment](#8415 (comment)) - `cargo-add` support, see [epage's comment](#8415 (comment)) - Optimizations, as needed

Part 7 of RFC2906 - Add support for inheriting `exclude` and `include` Tracking issue: #8415 RFC: rust-lang/rfcs#2906 Part 1: #10497 Part 2: #10517 Part 3: #10538 Part 4: #10548 Part 5: #10563 Part 6: #10564 This PR focuses on adding support for inheriting `include` and `exclude`. While they were not in the original RFC it was decided that they should be added per [epage's comment](#8415 (comment)). - Changed `include` and `exclude` into `Option<MaybeWorkspace<Vec<String>>>` inside `TomlProject` - Added `include` and `exclude` to `InheritbaleFields` - Updated tests to verify `include` and `exclude` are inheriting correctly Remaining implementation work for the RFC - `cargo-add` support, see [epage's comment](#8415 (comment)) - Optimizations, as needed

Part 8 of RFC2906 - Keep `InheritableFields` in a `LazyCell` inside `… Tracking issue: #8415 RFC: rust-lang/rfcs#2906 Part 1: #10497 Part 2: #10517 Part 3: #10538 Part 4: #10548 Part 5: #10563 Part 6: #10564 Part 7: #10565 This PR focuses on optimizations surrounding `InheritabeFields` and searching for a `WorkspaceRootConfig`: - Keep `InheritableFields` in a `LazyCell` inside `to_real_manifest` so we only search for a workspace root once per `to_real_manifest` - Changed calls for getting a workspace root to use `inherit_cell.try_borrow_with()` [Testing Framework](https://gist.github.com/Muscraft/14f6879af27500e34584296edb468d15) Test Results: nest=1, runs=7, members=75, step=25 - 25 Members: - Optimized: 0.145s - Not Optimized: 0.181s - Normal: 0.141s - Percent change from Normal: 2.837% - 50 Members - Optimized: 0.152s - Not Optimized: 0.267s - Normal: 0.141s - Percent change from Normal: 7.801% nest=2, runs=7, members=75, step=25 - 25 Members - Optimized: 0.147s, - Not Optimized: 0.437s - Normal: 0.14s - Percent change from Normal: 5.0% - 50 Members - Optimized: 0.159s - Not Optimized: 1.023s - Normal: 0.141s - Percent change from Normal: 12.766% Using a `LazyCell` for `InheritableFields` brought down runtimes to more acceptable levels. It is worth noting that this is a very harsh test case and not one that represents real-world scenarios. That being said there are still some optimizations that could be done if we need to. The biggest one is making sure we only parse a `Cargo.toml` once. Remaining implementation work for the RFC - `cargo-add` support, see [epage's comment](#8415 (comment)) - More optimizations, as needed

Prefer `key.workspace = true` to `key = { workspace = true }` Tracking issue: #8415 RFC: rust-lang/rfcs#2906 Part 1: #10497 Part 2: #10517 Part 3: #10538 Part 4: #10548 Part 5: #10563 Part 6: #10564 Part 7: #10565 Part 8: #10568 This PR fell out of [this discussion](#10497 (comment)) regarding if `key.workspace = true` is better than `key = { workspace = true }`. Changes: - Made all fields into `field.workspace = true` - Made dependencies into `dep.workspace = true` when a they only specify `{ workspace = true }` Remaining implementation work for the RFC - `cargo-add` support, see [epage's comment](#8415 (comment)) - Optimizations as needed

-- Part 1 of RFC2906

ccb321a

rust-highfive assigned ehuss Mar 22, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 22, 2022

Muscraft mentioned this pull request Mar 22, 2022

Packages can inherit fields from their root workspace #9684

Closed

paulyoung mentioned this pull request Mar 22, 2022

Remove workspace duplication codebase-labs/icfs#10

Open

epage reviewed Mar 22, 2022

View reviewed changes

-- updated both resolve to only take a get_ws

c4cd152

-- `resolve` not takes `get_ws: impl FnOnce() -> CargoResult<T>` -- removed `MaybeWorkspace` from `readme` and `license-file` -- changed error messages and test names

epage mentioned this pull request Mar 23, 2022

Tracking issue for Deduplicate Cargo workspace information RFC #8415

Closed

12 tasks

epage reviewed Mar 23, 2022

View reviewed changes

src/cargo/core/workspace.rs Outdated Show resolved Hide resolved

epage reviewed Mar 23, 2022

View reviewed changes

src/cargo/util/toml/mod.rs Outdated Show resolved Hide resolved

epage reviewed Mar 23, 2022

View reviewed changes

-- renamed deduplicate_workspace to inheritable_workspace_fields

e6992d4

-- removed `[]` from error messages in favor of back-ticks

epage approved these changes Mar 23, 2022

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 25, 2022

Muscraft mentioned this pull request Mar 29, 2022

Part 2 of RFC2906 -- allow inheriting from a different Cargo.toml #10517

Merged

ehuss mentioned this pull request Mar 31, 2022

Update cargo rust-lang/rust#95507

Merged

lucas-cauhe mentioned this pull request Mar 31, 2022

Import milli only once in Meilisearch meilisearch/meilisearch#2265

Closed

Muscraft mentioned this pull request Apr 6, 2022

Part 3 of RFC2906 - Add support for inheriting license-path, and depednency.path #10538

Merged

ehuss added this to the 1.61.0 milestone Apr 7, 2022

Muscraft mentioned this pull request Apr 8, 2022

Part 4 of RFC2906 - Add support for inheriting readme #10548

Merged

Muscraft mentioned this pull request Apr 13, 2022

Part 5 of RFC2906 - Add support for inheriting rust-version #10563

Merged

Muscraft mentioned this pull request Apr 13, 2022

Part 6 of RFC2906 - Switch the inheritance source from workspace to… #10564

Merged

Muscraft mentioned this pull request Apr 13, 2022

Part 7 of RFC2906 - Add support for inheriting exclude and include #10565

Merged

Muscraft mentioned this pull request Apr 14, 2022

Part 8 of RFC2906 - Keep InheritableFields in a LazyCell inside `… #10568

Merged

Muscraft mentioned this pull request Apr 20, 2022

Prefer key.workspace = true to key = { workspace = true } #10584

Merged

This was referenced Apr 27, 2022

Support overwriting a foo.workspace = true with a dependency from a… Muscraft/cargo#4

Merged

Cargo add support for workspace inheritance #10606

Merged

Andrewmatilde mentioned this pull request May 23, 2022

Add TLS support for http chaos-mesh/chaos-tproxy#39

Merged

5 tasks

Muscraft deleted the rfc2906-part1 branch May 27, 2022 01:16

matklad mentioned this pull request Jun 20, 2022

Consider re-exporting rocksdb crate from store near/nearcore#6301

Closed

ehuss mentioned this pull request Nov 7, 2023

cargo build panic 'target' specifier cannot be used without an 'artifact = …' #10634

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Part 1 of RFC2906 - Packages can inherit fields from their root workspace #10497

Part 1 of RFC2906 - Packages can inherit fields from their root workspace #10497

Muscraft commented Mar 22, 2022 •

edited by epage

Loading

rust-highfive commented Mar 22, 2022

epage commented Mar 22, 2022

epage left a comment

Muscraft commented Mar 23, 2022

epage commented Mar 23, 2022

Muscraft commented Mar 23, 2022

epage commented Mar 23, 2022

Muscraft commented Mar 23, 2022

epage commented Mar 23, 2022

epage left a comment

epage commented Mar 23, 2022

Muscraft commented Mar 23, 2022

epage commented Mar 23, 2022

Muscraft commented Mar 23, 2022

epage left a comment

Muscraft commented Mar 23, 2022

epage commented Mar 25, 2022

bors commented Mar 25, 2022

Part 1 of RFC2906 - Packages can inherit fields from their root workspace #10497

Part 1 of RFC2906 - Packages can inherit fields from their root workspace #10497

Conversation

Muscraft commented Mar 22, 2022 • edited by epage Loading

rust-highfive commented Mar 22, 2022

epage commented Mar 22, 2022

epage left a comment

Choose a reason for hiding this comment

Muscraft commented Mar 23, 2022

epage commented Mar 23, 2022

Muscraft commented Mar 23, 2022

epage commented Mar 23, 2022

Muscraft commented Mar 23, 2022

epage commented Mar 23, 2022

epage left a comment

Choose a reason for hiding this comment

epage commented Mar 23, 2022

Muscraft commented Mar 23, 2022

epage commented Mar 23, 2022

Muscraft commented Mar 23, 2022

epage left a comment

Choose a reason for hiding this comment

Muscraft commented Mar 23, 2022

epage commented Mar 25, 2022

bors commented Mar 25, 2022

Muscraft commented Mar 22, 2022 •

edited by epage

Loading