-
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 scripts try to build a nearby src/lib.rs
if present
#14476
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: