Ed Page

I can work around this by mutating the fields but in general, it doesn't seem to be separating concerns appropriately.

> Maybe what you're reporting here is that FormatOptions are not a property of Snippet and instead should be separate and passed together into DisplayList builder? Yes, separating styling from...

> This is necessary for binaries because developers will expect that when they cargo build locally in their workspace, then cargo publish && cargo install the same feature-resolution algorithm will...

@ehuss looks like you added all of this in #8129. Happen to remember if its intentional that `TomlManifest::prepare_for_publish` will only put the workspace's resolver version into the published manifest if...

> but if we get a future edition 2030 which implies resolver 3 While normally I don't like punting on problems as people are likely to forget about them, in...

A complication to exposing the target triplet is that I believe we build proc macros and build scripts once for the host, independent of which target platform is currently selected.

@ehuss my comment in #5784 used the `workspace.edition = "2018"` syntax because that is what is in the inheritance RFC, the current inheritance implementation has the syntax as `workspace.package.edition =...

> Unless anyone has particular ideas on how to deal with that, I'm leaning towards just closing this. Let's at least leave this open until 2906 is stablized in case...

btw https://github.com/rust-lang/cargo/issues/10498 exists for moving cargo-edit's cargo-upgrade into cargo. I wonder if `cargo outdated` could be a resolved via `cargo update` and `cargo upgrade` via - Dry-run support - An...

cargo upgrade v0.10.3 now provides a table summary of upgrades. This doesn't completely replace `cargo outdated` as this only handles root dependencies. I still hope we could have `cargo update`...