-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo publish has bad error message when explicit [[bench]]
isn't in package.include
#13456
Comments
include = ["src/", "LICENSE-*", "README.md", "CHANGELOG.md", "COPYRIGHT"] This doesn't include When you use auto-detected benches, When you add Possible ways to improve the experience for this:
|
I might be wrong, but doesn't crater run rely on tests being published to crates.io? |
[[bench]]
isn't in package.include
I meant "strip them if they aren't included", not "unconditionally strip them". It could also likely be a user-controlled lint so people can control whether they want to error or allow it (#12235). |
Isn't inclusion in the package a separate issue? I would expect [[bench]]
name = "uniform"
harness = false to behave identically to [[bench]]
name = "uniform"
path = "benches/uniform.rs"
harness = false where |
Interesting, I hadn't realized that the presence of The reason is that without This makes me think we'll only be able to handle this by stripping these target as erroring would likely break some existing cases. We could still warn though and once that is user controllable, they could turn that into an error. |
I think I'm hitting a variant of this, testing with
Which gives me
I can work around this by not excluding benches (but that's not the desired behavior), or by setting |
refactor(toml): Flatten manifest parsing ### What does this PR try to resolve? This is just a clean up but the goals are - Support diagnostics that show source by tracking `&str`, `ImDocument`, etc in `Manifest` by making each accessible in the creation of a `Manifest` - Defer warning analysis until we know what is a local vs non-local workspace by refactoring warnings out into a dedicated step - Centralize the logic for `cargo publish` stripping of dev-dependencies and their feature activations by allowing a `Summary` to be created from any "resolved" `TomlManifest` - Enumerate all build targets in the "resolved" `TomlManifest` so they get included in `cargo publish`, reducing the work done on registry dependencies and resolving problems like #13456 Along the way, this fixed a bug where we were not reporting warnings from virtual manifests ### How should we test and review this PR? ### Additional information
fix(toml): Warn on unused workspace.dependencies keys on virtual workspaces ### What does this PR try to resolve? This splits out refactors that build on #13589 in preparation for resolving #13456. As part of those refactors, I noticed an inconsistency on when we warn for unused keys. We have parallel code paths between `to_virtual_manifest` and `to_real_manifest` and only one got updated on a change. This syncs them up. Hopefully the end state this builds to will reduce duplication. ### How should we test and review this PR? ### Additional information
fix(toml): Warn on unused workspace.dependencies keys on virtual workspaces ### What does this PR try to resolve? This splits out refactors that build on #13589 in preparation for resolving #13456. As part of those refactors, I noticed an inconsistency on when we warn for unused keys. We have parallel code paths between `to_virtual_manifest` and `to_real_manifest` and only one got updated on a change. This syncs them up. Hopefully the end state this builds to will reduce duplication. ### How should we test and review this PR? ### Additional information
refactor(package): Simplify getting of published Manifest ### What does this PR try to resolve? This is a parallel effort to #13664 in an effort to #13456 This abstracts away the logic for getting the published version of `Cargo.toml` so we can more easily change the APIs that were previously exposed ### How should we test and review this PR? ### Additional information
At the time of upload,setting cargo book:
I understand the implication here is that with |
@heisen-li have not checked the code but I believe this is about target path auto-discovery inconsistency when packaging, not compiling default targets. |
btw i have a solution in work. I am working to make it so published packages have all targets explicitly enumerated. |
refactor(toml): Split out an explicit step to resolve `Cargo.toml` ### What does this PR try to resolve? This builds on #13664 and #13666. Currently, once we have deserialized `Cargo.toml`, we pass it to a large machinery (`to_real_manifest`, `to_virtual_manifest`) so that - `Cargo.toml` is resolved - `Summary` is created - `Manifest` is created This splits out the resolving of `Cargo.toml` which is mostly workspace inheritance today. While splitting logic conjoined like this can be a bit messy in the short term, the hope is that overall this makes the logic easier to follow (more condensed, focused sections to view; more explicit inputs/outputs). In particular, I hope that this will make it clearer and easier to shift more logic into the resolving step, specifically the inferring of build targets for #13456. ### How should we test and review this PR? This is broken up into very small steps in the hope that it makes it easier to analyze a step. ### Additional information
Problem
cargo publish
failsSteps
Using the latest rand commit:
Possible Solution(s)
No response
Notes
The relevant part of the
Cargo.toml
:This could have a
path
specified... but as far as I can tell,cargo publish
is the only thing not happy to discover the default path (benches/uniform.rs
).Despite this, the benchmark works fine:
Steps
Cargo.toml
#13693Version
The text was updated successfully, but these errors were encountered: