Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #12971 - epage:schema, r=Muscraft
refactor(toml): Clean up workspace inheritance ### What does this PR try to resolve? The goal is to simplify the code so we have a better boundary between `toml/mod.rs` and `toml/schema.rs` for when we break `toml/schema.rs` into a separate package for #12801. This let us - Remove a trait used in some back and forth for error handling - Move a lot of the inheritable bookkeeping and logic out of `schema.rs` A lot of these changes were inspired by [`cargo_toml`](https://docs.rs/cargo_toml/latest/cargo_toml/). This included some renaming that I felt made the code clearer. I didn't go as far as `cargo_toml`, yet. - They derive more `Deserializers`, producing worse errors - Their equivalent of `InheritableField` has an `inherit` function on it. They eagerly inherit things and then error if anything isn't inherited - I'm still toying with something like this but held off for now - One idea is `InheritableField` has an `inherit_with` function, like today, that only passes errors up but doesn't generate an error. We then have a `get` function that errors if it isn't inherited. We could encode the field names, for error reporting, into a type parameter for `InheritableField` - They flatten `InheritableDependency` into `TomlDependency` - By splitting these up, `workspace.dependencies` and `.cargo/config.toml` code can directly use `TomlDependency` without extra error handling -If we went this rout, I think I'd merge`InheritableDependency::Inherit` with `DetailedDependency`, having callers handle the errors (much like `TomlManifest` is both a real and virtual) Some things I'm trying to balance - Complexity - Quality of error messages - Knowing what code needs touching when changes are made - Some more work is needed here ### How should we test and review this PR? ### Additional information
- Loading branch information