-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Cargo scripts try to build a nearby src/lib.rs
if present
#14476
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
It looks like this is because you are using an older syntax //! ```cargo
//! [package]
//! edition = "2021"
//! ```
We dropped support for the doc-comment syntax in favor of rust-lang/rfcs#3503 I've verified the following does not produce the warning: #!/usr/bin/env nargo
---
[package]
edition = "2021"
---
fn main () {
} |
We do, for bins, tests, benches, examples, and build scripts I overlooked that we don't have a way to control auto-discovery of lib targets. We'll either need to hack this in or add a control mechanism for lib auto-discovery. |
src/lib.rs
if present
PR rust-lang#5335 added `autobins`, etc for rust-lang#5330. Nowhere in there is discussion of `autolib`. Cargo script disables support for additional build-targets by disabling discovery. Except we don't have a way to disable discovery of `autolib`, leading to rust-lang#14476. By adding `autolib`, we can continue in that direction. This also allows us to bypass inferring of libs on published packages, like all other build-targets which were handled in rust-lang#13849. As this seems fairly low controversy, this insta-stabilizes the field. In prior versions of Cargo, users will get an "unused manifest key" warning. For packags where this is set by `cargo publish`, the warning will be suppressed and things will work as normal. For `cargo vendor`, the same except there will be some churn in the vendored source as this field will now be set. For local development, it should be rare to set `autolib` so the lack of error by discovering a file when this is set shouldn't be a problem. Fixes rust-lang#14476
PR rust-lang#5335 added `autobins`, etc for rust-lang#5330. Nowhere in there is discussion of `autolib`. Cargo script disables support for additional build-targets by disabling discovery. Except we don't have a way to disable discovery of `autolib`, leading to rust-lang#14476. By adding `autolib`, we can continue in that direction. This also allows us to bypass inferring of libs on published packages, like all other build-targets which were handled in rust-lang#13849. As this seems fairly low controversy, this insta-stabilizes the field. In prior versions of Cargo, users will get an "unused manifest key" warning. For packags where this is set by `cargo publish`, the warning will be suppressed and things will work as normal. For `cargo vendor`, the same except there will be some churn in the vendored source as this field will now be set. For local development, it should be rare to set `autolib` so the lack of error by discovering a file when this is set shouldn't be a problem. Fixes rust-lang#14476
PR rust-lang#5335 added `autobins`, etc for rust-lang#5330. Nowhere in there is discussion of `autolib`. Cargo script disables support for additional build-targets by disabling discovery. Except we don't have a way to disable discovery of `autolib`, leading to rust-lang#14476. By adding `autolib`, we can continue in that direction. This also allows us to bypass inferring of libs on published packages, like all other build-targets which were handled in rust-lang#13849. As this seems fairly low controversy, this insta-stabilizes the field. In prior versions of Cargo, users will get an "unused manifest key" warning. For packags where this is set by `cargo publish`, the warning will be suppressed and things will work as normal. For `cargo vendor`, the same except there will be some churn in the vendored source as this field will now be set. For local development, it should be rare to set `autolib` so the lack of error by discovering a file when this is set shouldn't be a problem. Fixes rust-lang#14476
PR rust-lang#5335 added `autobins`, etc for rust-lang#5330. Nowhere in there is discussion of `autolib`. Cargo script disables support for additional build-targets by disabling discovery. Except we don't have a way to disable discovery of `autolib`, leading to rust-lang#14476. By adding `autolib`, we can continue in that direction. This also allows us to bypass inferring of libs on published packages, like all other build-targets which were handled in rust-lang#13849. As this seems fairly low controversy, this insta-stabilizes the field. In prior versions of Cargo, users will get an "unused manifest key" warning. For packags where this is set by `cargo publish`, the warning will be suppressed and things will work as normal. For `cargo vendor`, the same except there will be some churn in the vendored source as this field will now be set. For local development, it should be rare to set `autolib` so the lack of error by discovering a file when this is set shouldn't be a problem. Fixes rust-lang#14476
feat(toml): Add `autolib` ### What does this PR try to resolve? PR #5335 added `autobins`, etc for #5330. Nowhere in there is discussion of `autolib`. Cargo script disables support for additional build-targets by disabling discovery. Except we don't have a way to disable discovery of `autolib`, leading to #14476. By adding `autolib`, we can continue in that direction. This also allows us to bypass inferring of libs on published packages, like all other build-targets which were handled in #13849. Fixes #14476 ### How should we test and review this PR? ### Additional information As this seems fairly low controversy, this insta-stabilizes the field. In prior versions of Cargo, users will get an "unused manifest key" warning. For packages where this is set by `cargo publish`, the warning will be suppressed and things will work as normal. For `cargo vendor`, the same except there will be some churn in the vendored source as this field will now be set. For local development, it should be rare to set `autolib` so the lack of error by discovering a file when this is set shouldn't be a problem.
Problem
If I place a script in the same directory as a crate, it uses crate's source files, but does not use crate's dependencies, causing unexpected compilation errors.
Steps
./Cargo.toml
:./src/lib.rs
:./script.rs
:Running
./script.rs
causes:This looks broken, because
src/lib.rs
is compiled with scripts dependencies, not its usual crate dependencies.Possible Solution(s)
I would expect
Cargo.toml
andsrc/
to be completely ignored by the scripts. Or if they're not ignored, to be compiled correctly as a library and included as an external crate in the script (liketests/
ormain.rs
get). But compiling the crate, but with a wrongCargo.toml
context seems like the worst of both.Notes
BTW, "warning:
package.edition
is unspecified, defaulting to2021
" is printed, even though I've tried to specify it in all places.Version
The text was updated successfully, but these errors were encountered: