development/cargo
development/cargo
1
0
Fork 0
mirror of https://github.com/rust-lang/cargo synced 2024-10-31 08:59:36 +00:00
Code Issues Projects Releases Packages Wiki Activity
cargo/tests/testsuite/metadata.rs

4546 lines
136 KiB
Rust
Raw Normal View History

Minor testsuite organization.
2019-11-25 02:42:45 +00:00
//! Tests for the `cargo metadata` command.
Add tests for fixed metadata download behavior
2020-12-17 18:01:24 +00:00
use cargo_test_support::install::cargo_home;
use cargo_test_support::paths::CargoPathExt;
Extract `support` directory to its own crate Extract out all our test support code to its own standalone crate so it can be shared between multiple test suites if necessary.
2019-09-12 17:14:29 +00:00
use cargo_test_support::registry::Package;
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
use cargo_test_support::{basic_bin_manifest, basic_lib_manifest, main_file, project, rustc_host};
Fix `package_default_run`. The output was checking the `targets`, whose order depends on the filesystem order. Instead of checking all the output, just check the one field this test is for.
2021-06-11 23:08:20 +00:00
use serde_json::json;
Introduce cargo metadata subcommand Most of the work was done by @dan-t in #1225 and by @winger in #1434 Fixes #2193
2015-12-05 00:22:54 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn cargo_metadata_simple() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/foo.rs", "")
.file("Cargo.toml", &basic_bin_manifest("foo"))
.build();
Introduce cargo metadata subcommand Most of the work was done by @dan-t in #1225 and by @winger in #1434 Fixes #2193
2015-12-05 00:22:54 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata")
.with_json(
cargo fmt
2018-03-14 15:17:44 +00:00
r#"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
{
"packages": [
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [
"wycats@example.com"
],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"name": "foo",
"version": "0.5.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.5.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"source": null,
"dependencies": [],
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
cargo: add license and license_file to cargo metadata output
2016-09-25 21:57:51 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Metadata response now also contains package description.
2017-02-02 07:59:34 +00:00
"description": null,
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
"homepage": null,
"documentation": null,
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"targets": [
{
"kind": [
"bin"
],
Fixed tests
2017-02-08 15:15:06 +00:00
"crate_types": [
"bin"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": false,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"name": "foo",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]/foo/src/foo.rs"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
}
],
"features": {},
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"manifest_path": "[..]Cargo.toml",
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"metadata": null,
"publish": null
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"workspace_members": ["path+file:[..]foo#0.5.0"],
"workspace_default_members": ["path+file:[..]foo#0.5.0"],
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"resolve": {
metadata: change resolve serialization
2016-01-29 20:47:16 +00:00
"nodes": [
{
"dependencies": [],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"deps": [],
Repair the other metadata tests
2018-03-05 14:36:12 +00:00
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.5.0"
metadata: change resolve serialization
2016-01-29 20:47:16 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]foo#0.5.0"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"target_directory": "[..]foo/target",
Add workspace root to metadata command. Fixes #4933
2018-01-13 19:51:36 +00:00
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
cargo fmt
2018-03-14 15:17:44 +00:00
}"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Introduce cargo metadata subcommand Most of the work was done by @dan-t in #1225 and by @winger in #1434 Fixes #2193
2015-12-05 00:22:54 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Encourage tools writers to explicitly pin metadata version
2017-03-17 15:00:29 +00:00
fn cargo_metadata_warns_on_implicit_version() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
Encourage tools writers to explicitly pin metadata version
2017-03-17 15:00:29 +00:00
.file("src/foo.rs", "")
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("Cargo.toml", &basic_bin_manifest("foo"))
.build();
Encourage tools writers to explicitly pin metadata version
2017-03-17 15:00:29 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata").with_stderr("[WARNING] please specify `--format-version` flag explicitly to avoid compatibility problems").run();
Encourage tools writers to explicitly pin metadata version
2017-03-17 15:00:29 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --format-version 1").with_stderr("").run();
Encourage tools writers to explicitly pin metadata version
2017-03-17 15:00:29 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
fn library_with_several_crate_types() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/lib.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
[package]
name = "foo"
version = "0.5.0"
[lib]
crate-type = ["lib", "staticlib"]
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata")
.with_json(
cargo fmt
2018-03-14 15:17:44 +00:00
r#"
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
{
"packages": [
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
"name": "foo",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
"version": "0.5.0",
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.5.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
"source": null,
"dependencies": [],
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
"description": null,
"targets": [
{
"kind": [
"lib",
"staticlib"
],
"crate_types": [
"lib",
"staticlib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
"name": "foo",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]/foo/src/lib.rs"
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
}
],
"features": {},
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"manifest_path": "[..]Cargo.toml",
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"metadata": null,
"publish": null
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"workspace_members": ["path+file:[..]foo#0.5.0"],
"workspace_default_members": ["path+file:[..]foo#0.5.0"],
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
"resolve": {
"nodes": [
{
"dependencies": [],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"deps": [],
Repair the other metadata tests
2018-03-05 14:36:12 +00:00
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.5.0"
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]foo#0.5.0"
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"target_directory": "[..]foo/target",
Add workspace root to metadata command. Fixes #4933
2018-01-13 19:51:36 +00:00
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
cargo fmt
2018-03-14 15:17:44 +00:00
}"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
}
metadata: serialize Resolve
2015-12-21 15:05:26 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
fn library_with_features() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
.file("src/lib.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
[package]
name = "foo"
version = "0.5.0"
[features]
default = ["default_feat"]
default_feat = []
optional_feat = []
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata")
.with_json(
cargo fmt
2018-03-14 15:17:44 +00:00
r#"
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
{
"packages": [
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
"name": "foo",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
"version": "0.5.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.5.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
"source": null,
"dependencies": [],
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
"description": null,
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
"name": "foo",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]/foo/src/lib.rs"
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
}
],
"features": {
"default": [
Revert serialization of features to string type
2018-04-04 18:07:57 +00:00
"default_feat"
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
],
"default_feat": [],
"optional_feat": []
},
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"manifest_path": "[..]Cargo.toml",
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"metadata": null,
"publish": null
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"workspace_members": ["path+file:[..]foo#0.5.0"],
"workspace_default_members": ["path+file:[..]foo#0.5.0"],
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
"resolve": {
"nodes": [
{
"dependencies": [],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"deps": [],
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
"features": [
"default",
"default_feat"
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.5.0"
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]foo#0.5.0"
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"target_directory": "[..]foo/target",
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
cargo fmt
2018-03-14 15:17:44 +00:00
}"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Emit resolve.features in "cargo metadata"
2018-03-05 06:04:27 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn cargo_metadata_with_deps_and_version() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
Fix metadata tests
2017-01-31 19:01:37 +00:00
.file("src/foo.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
name = "foo"
version = "0.5.0"
authors = []
license = "MIT"
description = "foo"
metadata: serialize Resolve
2015-12-21 15:05:26 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[[bin]]
name = "foo"
metadata: serialize Resolve
2015-12-21 15:05:26 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = "*"
[dev-dependencies]
foobar = "*"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
metadata: serialize Resolve
2015-12-21 15:05:26 +00:00
Package::new("baz", "0.0.1").publish();
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
Package::new("foobar", "0.0.1").publish();
metadata: serialize Resolve
2015-12-21 15:05:26 +00:00
Package::new("bar", "0.0.1").dep("baz", "0.0.1").publish();
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata -q --format-version 1")
.with_json(
cargo fmt
2018-03-14 15:17:44 +00:00
r#"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
{
"packages": [
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
{
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"dependencies": [
{
"features": [],
"kind": null,
"name": "baz",
"optional": false,
"registry": null,
"rename": null,
"req": "^0.0.1",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"target": null,
"uses_default_features": true
}
],
"description": null,
"edition": "2015",
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#bar@0.0.1",
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]Cargo.toml",
"metadata": null,
"publish": null,
"name": "bar",
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"source": "registry+https://github.com/rust-lang/crates.io-index",
"targets": [
{
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"edition": "2015",
"kind": [
"lib"
],
"name": "bar",
"src_path": "[..]src/lib.rs"
}
],
"version": "0.0.1"
},
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"dependencies": [],
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"description": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"edition": "2015",
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#baz@0.0.1",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"manifest_path": "[..]Cargo.toml",
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"metadata": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"publish": null,
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"name": "baz",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Use correct registry on tests/testsuite/metadata.rs
2018-12-10 22:10:43 +00:00
"source": "registry+https://github.com/rust-lang/crates.io-index",
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"targets": [
{
Fixed tests
2017-02-08 15:15:06 +00:00
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"kind": [
"lib"
],
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"name": "baz",
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"src_path": "[..]src/lib.rs"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
}
],
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"version": "0.0.1"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
},
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"dependencies": [
{
"features": [],
"kind": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"name": "bar",
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"optional": false,
Add dependency `registry` to `cargo metadata`. This adds the `registry` field for dependencies for alternate registries in `cargo metadata`.
2018-12-30 04:46:15 +00:00
"registry": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"rename": null,
"req": "*",
Use correct registry on tests/testsuite/metadata.rs
2018-12-10 22:10:43 +00:00
"source": "registry+https://github.com/rust-lang/crates.io-index",
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"target": null,
"uses_default_features": true
},
{
"features": [],
"kind": "dev",
"name": "foobar",
"optional": false,
Add dependency `registry` to `cargo metadata`. This adds the `registry` field for dependencies for alternate registries in `cargo metadata`.
2018-12-30 04:46:15 +00:00
"registry": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"rename": null,
"req": "*",
Use correct registry on tests/testsuite/metadata.rs
2018-12-10 22:10:43 +00:00
"source": "registry+https://github.com/rust-lang/crates.io-index",
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"target": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"uses_default_features": true
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
}
],
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"description": "foo",
"edition": "2015",
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.5.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"license": "MIT",
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"manifest_path": "[..]Cargo.toml",
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"metadata": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"publish": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"name": "foo",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"source": null,
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"targets": [
{
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"crate_types": [
"bin"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": false,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"edition": "2015",
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
"kind": [
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"bin"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
],
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"name": "foo",
"src_path": "[..]src/foo.rs"
}
],
"version": "0.5.0"
},
{
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"dependencies": [],
"description": null,
"edition": "2015",
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#foobar@0.0.1",
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"keywords": [],
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"manifest_path": "[..]Cargo.toml",
"metadata": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"publish": null,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"name": "foobar",
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Use correct registry on tests/testsuite/metadata.rs
2018-12-10 22:10:43 +00:00
"source": "registry+https://github.com/rust-lang/crates.io-index",
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"targets": [
{
Fixed tests
2017-02-08 15:15:06 +00:00
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"kind": [
"lib"
],
"name": "foobar",
"src_path": "[..]src/lib.rs"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
}
],
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"version": "0.0.1"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
}
],
"resolve": {
metadata: change resolve serialization
2016-01-29 20:47:16 +00:00
"nodes": [
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
{
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"registry+https://github.com/rust-lang/crates.io-index#baz@0.0.1"
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
],
"deps": [
{
"dep_kinds": [
{
"kind": null,
"target": null
}
],
"name": "baz",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#baz@0.0.1"
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
}
],
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#bar@0.0.1"
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
},
{
"dependencies": [],
"deps": [],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#baz@0.0.1"
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
},
metadata: change resolve serialization
2016-01-29 20:47:16 +00:00
{
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"registry+https://github.com/rust-lang/crates.io-index#bar@0.0.1",
"registry+https://github.com/rust-lang/crates.io-index#foobar@0.0.1"
metadata: change resolve serialization
2016-01-29 20:47:16 +00:00
],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"deps": [
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
{
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
],
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"name": "bar",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#bar@0.0.1"
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
},
{
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": "dev",
"target": null
}
],
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"name": "foobar",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#foobar@0.0.1"
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
}
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
],
Repair the other metadata tests
2018-03-05 14:36:12 +00:00
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.5.0"
metadata: change resolve serialization
2016-01-29 20:47:16 +00:00
},
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
{
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"dependencies": [],
"deps": [],
Repair the other metadata tests
2018-03-05 14:36:12 +00:00
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#foobar@0.0.1"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]foo#0.5.0"
metadata: use existing infra for JSON output
2016-01-24 21:16:33 +00:00
},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"target_directory": "[..]foo/target",
Add workspace root to metadata command. Fixes #4933
2018-01-13 19:51:36 +00:00
"version": 1,
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]foo#0.5.0"
Add dev-dependencies test on cargo_metadata_with_deps_and_version
2018-12-09 18:35:34 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]foo#0.5.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
cargo fmt
2018-03-14 15:17:44 +00:00
}"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
metadata: serialize Resolve
2015-12-21 15:05:26 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Added tests
2017-02-08 15:28:36 +00:00
fn example() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/lib.rs", "")
.file("examples/ex.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Added tests
2017-02-08 15:28:36 +00:00
[package]
name = "foo"
version = "0.1.0"
[[example]]
name = "ex"
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
Added tests
2017-02-08 15:28:36 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata")
.with_json(
cargo fmt
2018-03-14 15:17:44 +00:00
r#"
Added tests
2017-02-08 15:28:36 +00:00
{
"packages": [
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Added tests
2017-02-08 15:28:36 +00:00
"name": "foo",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Added tests
2017-02-08 15:28:36 +00:00
"version": "0.1.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.1.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
Added tests
2017-02-08 15:28:36 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Added tests
2017-02-08 15:28:36 +00:00
"description": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
Added tests
2017-02-08 15:28:36 +00:00
"source": null,
"dependencies": [],
"targets": [
{
"kind": [ "lib" ],
"crate_types": [ "lib" ],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
Added tests
2017-02-08 15:28:36 +00:00
"name": "foo",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]/foo/src/lib.rs"
Added tests
2017-02-08 15:28:36 +00:00
},
{
"kind": [ "example" ],
Fix crate_types in serialized targets
2017-03-24 07:40:12 +00:00
"crate_types": [ "bin" ],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": false,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": false,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": false,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
Added tests
2017-02-08 15:28:36 +00:00
"name": "ex",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]/foo/examples/ex.rs"
Added tests
2017-02-08 15:28:36 +00:00
}
],
"features": {},
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"manifest_path": "[..]Cargo.toml",
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"metadata": null,
"publish": null
Added tests
2017-02-08 15:28:36 +00:00
}
],
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]foo#0.1.0"
Added tests
2017-02-08 15:28:36 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]foo#0.1.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
Added tests
2017-02-08 15:28:36 +00:00
"resolve": {
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file://[..]foo#0.1.0",
Added tests
2017-02-08 15:28:36 +00:00
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.1.0",
Repair the other metadata tests
2018-03-05 14:36:12 +00:00
"features": [],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"dependencies": [],
"deps": []
Added tests
2017-02-08 15:28:36 +00:00
}
]
},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"target_directory": "[..]foo/target",
Add workspace root to metadata command. Fixes #4933
2018-01-13 19:51:36 +00:00
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
cargo fmt
2018-03-14 15:17:44 +00:00
}"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Added tests
2017-02-08 15:28:36 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Added tests
2017-02-08 15:28:36 +00:00
fn example_lib() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/lib.rs", "")
.file("examples/ex.rs", "")
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Added tests
2017-02-08 15:28:36 +00:00
[package]
name = "foo"
version = "0.1.0"
[[example]]
name = "ex"
Fixed tests
2017-02-09 18:20:56 +00:00
crate-type = ["rlib", "dylib"]
cargo fmt
2018-03-14 15:17:44 +00:00
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
Added tests
2017-02-08 15:28:36 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata")
.with_json(
cargo fmt
2018-03-14 15:17:44 +00:00
r#"
Added tests
2017-02-08 15:28:36 +00:00
{
"packages": [
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Added tests
2017-02-08 15:28:36 +00:00
"name": "foo",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Added tests
2017-02-08 15:28:36 +00:00
"version": "0.1.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.1.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
Added tests
2017-02-08 15:28:36 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Added tests
2017-02-08 15:28:36 +00:00
"description": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
Added tests
2017-02-08 15:28:36 +00:00
"source": null,
"dependencies": [],
"targets": [
{
"kind": [ "lib" ],
"crate_types": [ "lib" ],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
Added tests
2017-02-08 15:28:36 +00:00
"name": "foo",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]/foo/src/lib.rs"
Added tests
2017-02-08 15:28:36 +00:00
},
{
"kind": [ "example" ],
Fixed tests
2017-02-09 18:20:56 +00:00
"crate_types": [ "rlib", "dylib" ],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": false,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": false,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": false,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
Added tests
2017-02-08 15:28:36 +00:00
"name": "ex",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]/foo/examples/ex.rs"
Added tests
2017-02-08 15:28:36 +00:00
}
],
"features": {},
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"manifest_path": "[..]Cargo.toml",
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"metadata": null,
"publish": null
Added tests
2017-02-08 15:28:36 +00:00
}
],
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]foo#0.1.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]foo#0.1.0"
Added tests
2017-02-08 15:28:36 +00:00
],
"resolve": {
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file://[..]foo#0.1.0",
Added tests
2017-02-08 15:28:36 +00:00
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.1.0",
Repair the other metadata tests
2018-03-05 14:36:12 +00:00
"features": [],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"dependencies": [],
"deps": []
Added tests
2017-02-08 15:28:36 +00:00
}
]
},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"target_directory": "[..]foo/target",
Add workspace root to metadata command. Fixes #4933
2018-01-13 19:51:36 +00:00
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
cargo fmt
2018-03-14 15:17:44 +00:00
}"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Added tests
2017-02-08 15:28:36 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
fn workspace_metadata() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[workspace]
members = ["bar", "baz"]
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[workspace.metadata]
tool1 = "hello"
tool2 = [1, 2, 3]
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[workspace.metadata.foo]
bar = 3
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("bar/Cargo.toml", &basic_lib_manifest("bar"))
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
.file("bar/src/lib.rs", "")
.file("baz/Cargo.toml", &basic_lib_manifest("baz"))
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("baz/src/lib.rs", "")
.build();
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata")
.with_json(
cargo fmt
2018-03-14 15:17:44 +00:00
r#"
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
{
"packages": [
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [
"wycats@example.com"
],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"name": "bar",
"version": "0.5.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]bar#0.5.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"source": null,
"dependencies": [],
cargo: add license and license_file to cargo metadata output
2016-09-25 21:57:51 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Metadata response now also contains package description.
2017-02-02 07:59:34 +00:00
"description": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"targets": [
{
"kind": [ "lib" ],
Fixed tests
2017-02-08 15:15:06 +00:00
"crate_types": [ "lib" ],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"name": "bar",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]bar/src/lib.rs"
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
}
],
"features": {},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"manifest_path": "[..]bar/Cargo.toml",
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"metadata": null,
"publish": null
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
},
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [
"wycats@example.com"
],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"name": "baz",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"version": "0.5.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]baz#0.5.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"source": null,
"dependencies": [],
cargo: add license and license_file to cargo metadata output
2016-09-25 21:57:51 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Metadata response now also contains package description.
2017-02-02 07:59:34 +00:00
"description": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"targets": [
{
"kind": [ "lib" ],
Fixed tests
2017-02-08 15:15:06 +00:00
"crate_types": [ "lib" ],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"name": "baz",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]baz/src/lib.rs"
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
}
],
"features": {},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"manifest_path": "[..]baz/Cargo.toml",
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"metadata": null,
"publish": null
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"workspace_members": [
"path+file:[..]bar#0.5.0",
"path+file:[..]baz#0.5.0"
],
"workspace_default_members": [
"path+file:[..]bar#0.5.0",
"path+file:[..]baz#0.5.0"
],
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"resolve": {
"nodes": [
{
"dependencies": [],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"deps": [],
Repair the other metadata tests
2018-03-05 14:36:12 +00:00
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]bar#0.5.0"
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
},
{
"dependencies": [],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"deps": [],
Repair the other metadata tests
2018-03-05 14:36:12 +00:00
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]baz#0.5.0"
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
}
],
"root": null
},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"target_directory": "[..]foo/target",
Add workspace root to metadata command. Fixes #4933
2018-01-13 19:51:36 +00:00
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": {
"tool1": "hello",
"tool2": [1, 2, 3],
"foo": {
"bar": 3
}
}
cargo fmt
2018-03-14 15:17:44 +00:00
}"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
fn workspace_metadata_with_dependencies_no_deps() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
// NOTE that 'artifact' isn't mentioned in the workspace here, yet it shows up as member.
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[workspace]
members = ["bar", "baz"]
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
.file(
"bar/Cargo.toml",
r#"
[package]
name = "bar"
version = "0.5.0"
authors = ["wycats@example.com"]
[dependencies]
baz = { path = "../baz/" }
artifact = { path = "../artifact/", artifact = "bin" }
"#,
)
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
.file("bar/src/lib.rs", "")
.file("baz/Cargo.toml", &basic_lib_manifest("baz"))
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("baz/src/lib.rs", "")
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
.file("artifact/Cargo.toml", &basic_bin_manifest("artifact"))
.file("artifact/src/main.rs", "fn main() {}")
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.build();
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
p.cargo("metadata --no-deps -Z bindeps")
add a reason to `masquerade_as_nightly_cargo` so it is searchable
2022-07-16 02:32:23 +00:00
.masquerade_as_nightly_cargo(&["bindeps"])
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.with_json(
cargo fmt
2018-03-14 15:17:44 +00:00
r#"
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
{
"packages": [
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [
"wycats@example.com"
],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"name": "bar",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"version": "0.5.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]bar#0.5.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"source": null,
cargo: add license and license_file to cargo metadata output
2016-09-25 21:57:51 +00:00
"license": null,
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"dependencies": [
{
"features": [],
"kind": null,
"name": "artifact",
"optional": false,
"path": "[..]/foo/artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true,
"artifact": {
"kinds": [
"bin"
],
"lib": false,
"target": null
}
},
{
"features": [],
"kind": null,
"name": "baz",
"optional": false,
"path": "[..]/foo/baz",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
}
],
cargo: add license and license_file to cargo metadata output
2016-09-25 21:57:51 +00:00
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Metadata response now also contains package description.
2017-02-02 07:59:34 +00:00
"description": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"targets": [
{
"kind": [ "lib" ],
Fixed tests
2017-02-08 15:15:06 +00:00
"crate_types": [ "lib" ],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"name": "bar",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]bar/src/lib.rs"
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
}
],
"features": {},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"manifest_path": "[..]bar/Cargo.toml",
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"metadata": null,
"publish": null
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
},
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
{
"authors": [
"wycats@example.com"
],
"categories": [],
"default_run": null,
"dependencies": [],
"description": null,
"documentation": null,
"edition": "2015",
"features": {},
"homepage": null,
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]/foo/artifact#0.5.0",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]/foo/artifact/Cargo.toml",
"metadata": null,
"name": "artifact",
"publish": null,
"readme": null,
"repository": null,
"rust_version": null,
"source": null,
"targets": [
{
"crate_types": [
"bin"
],
"doc": true,
"doctest": false,
"edition": "2015",
"kind": [
"bin"
],
"name": "artifact",
"src_path": "[..]/foo/artifact/src/main.rs",
"test": true
}
],
"version": "0.5.0"
},
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [
"wycats@example.com"
],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"name": "baz",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"version": "0.5.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]baz#0.5.0",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"source": null,
"dependencies": [],
cargo: add license and license_file to cargo metadata output
2016-09-25 21:57:51 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Metadata response now also contains package description.
2017-02-02 07:59:34 +00:00
"description": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"targets": [
{
"kind": [ "lib" ],
Fixed tests
2017-02-08 15:15:06 +00:00
"crate_types": ["lib"],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
"name": "baz",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]baz/src/lib.rs"
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
}
],
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"features": {},
"manifest_path": "[..]baz/Cargo.toml",
"metadata": null,
"publish": null
}
],
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]bar#0.5.0",
"path+file:[..]/foo/artifact#0.5.0",
"path+file:[..]baz#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]bar#0.5.0",
"path+file:[..]/foo/artifact#0.5.0",
"path+file:[..]baz#0.5.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"resolve": null,
"target_directory": "[..]foo/target",
"version": 1,
"workspace_root": "[..]/foo",
"metadata": null
}"#,
)
.run();
}
#[cargo_test]
fn workspace_metadata_with_dependencies_and_resolve() {
let alt_target = "wasm32-unknown-unknown";
let p = project()
.file(
"Cargo.toml",
r#"
[workspace]
members = ["bar", "artifact", "non-artifact", "bin-only-artifact"]
"#,
)
.file(
"bar/Cargo.toml",
&r#"
[package]
name = "bar"
version = "0.5.0"
authors = []
Only output field `extern_name` when using -Zbindeps
2023-01-16 13:27:19 +00:00
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
[build-dependencies]
artifact = { path = "../artifact/", artifact = "bin", target = "target" }
bin-only-artifact = { path = "../bin-only-artifact/", artifact = "bin", target = "$ALT_TARGET" }
non-artifact = { path = "../non-artifact" }
Only output field `extern_name` when using -Zbindeps
2023-01-16 13:27:19 +00:00
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
[dependencies]
artifact = { path = "../artifact/", artifact = ["cdylib", "staticlib", "bin:baz-name"], lib = true, target = "$ALT_TARGET" }
bin-only-artifact = { path = "../bin-only-artifact/", artifact = "bin:a-name" }
non-artifact = { path = "../non-artifact" }
Only output field `extern_name` when using -Zbindeps
2023-01-16 13:27:19 +00:00
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
[dev-dependencies]
artifact = { path = "../artifact/" }
non-artifact = { path = "../non-artifact" }
bin-only-artifact = { path = "../bin-only-artifact/", artifact = "bin:b-name" }
"#.replace("$ALT_TARGET", alt_target),
)
.file("bar/src/lib.rs", "")
.file("bar/build.rs", "fn main() {}")
.file(
"artifact/Cargo.toml",
r#"
[package]
name = "artifact"
version = "0.5.0"
authors = []
[lib]
crate-type = ["staticlib", "cdylib", "rlib"]
[[bin]]
name = "bar-name"
[[bin]]
name = "baz-name"
"#,
)
.file("artifact/src/main.rs", "fn main() {}")
.file("artifact/src/lib.rs", "")
.file(
"bin-only-artifact/Cargo.toml",
r#"
[package]
name = "bin-only-artifact"
version = "0.5.0"
authors = []
[[bin]]
name = "a-name"
[[bin]]
name = "b-name"
"#,
)
.file("bin-only-artifact/src/main.rs", "fn main() {}")
.file("non-artifact/Cargo.toml",
r#"
[package]
name = "non-artifact"
version = "0.5.0"
authors = []
"#,
)
.file("non-artifact/src/lib.rs", "")
.build();
p.cargo("metadata -Z bindeps")
add a reason to `masquerade_as_nightly_cargo` so it is searchable
2022-07-16 02:32:23 +00:00
.masquerade_as_nightly_cargo(&["bindeps"])
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
.with_json(
r#"
{
"metadata": null,
"packages": [
{
"authors": [],
"categories": [],
"default_run": null,
"dependencies": [],
"description": null,
"documentation": null,
"edition": "2015",
"features": {},
"homepage": null,
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/artifact#0.5.0",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]/foo/artifact/Cargo.toml",
"metadata": null,
"name": "artifact",
"publish": null,
"readme": null,
"repository": null,
"rust_version": null,
"source": null,
"targets": [
{
"crate_types": [
"staticlib",
"cdylib",
"rlib"
],
"doc": true,
"doctest": true,
"edition": "2015",
"kind": [
"staticlib",
"cdylib",
"rlib"
],
"name": "artifact",
"src_path": "[..]/foo/artifact/src/lib.rs",
"test": true
},
{
"crate_types": [
"bin"
],
"doc": true,
"doctest": false,
"edition": "2015",
"kind": [
"bin"
],
"name": "bar-name",
"src_path": "[..]/foo/artifact/src/main.rs",
"test": true
},
{
"crate_types": [
"bin"
],
"doc": true,
"doctest": false,
"edition": "2015",
"kind": [
"bin"
],
"name": "baz-name",
"src_path": "[..]/foo/artifact/src/main.rs",
"test": true
}
],
"version": "0.5.0"
},
{
"authors": [],
"categories": [],
"default_run": null,
"dependencies": [
{
"artifact": {
"kinds": [
"cdylib",
"staticlib",
"bin:baz-name"
],
"lib": true,
"target": "wasm32-unknown-unknown"
},
"features": [],
"kind": null,
"name": "artifact",
"optional": false,
"path": "[..]/foo/artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"artifact": {
"kinds": [
"bin:a-name"
],
"lib": false,
"target": null
},
"features": [],
"kind": null,
"name": "bin-only-artifact",
"optional": false,
"path": "[..]/foo/bin-only-artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"features": [],
"kind": null,
"name": "non-artifact",
"optional": false,
"path": "[..]/foo/non-artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"features": [],
"kind": "dev",
"name": "artifact",
"optional": false,
"path": "[..]/foo/artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"artifact": {
"kinds": [
"bin:b-name"
],
"lib": false,
"target": null
},
"features": [],
"kind": "dev",
"name": "bin-only-artifact",
"optional": false,
"path": "[..]/foo/bin-only-artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"features": [],
"kind": "dev",
"name": "non-artifact",
"optional": false,
"path": "[..]/foo/non-artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"artifact": {
"kinds": [
"bin"
],
"lib": false,
"target": "target"
},
"features": [],
"kind": "build",
"name": "artifact",
"optional": false,
"path": "[..]/foo/artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"artifact": {
"kinds": [
"bin"
],
"lib": false,
"target": "wasm32-unknown-unknown"
},
"features": [],
"kind": "build",
"name": "bin-only-artifact",
"optional": false,
"path": "[..]/foo/bin-only-artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"features": [],
"kind": "build",
"name": "non-artifact",
"optional": false,
"path": "[..]/foo/non-artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
}
],
"description": null,
"documentation": null,
"edition": "2015",
"features": {},
"homepage": null,
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/bar#0.5.0",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]/foo/bar/Cargo.toml",
"metadata": null,
"name": "bar",
"publish": null,
"readme": null,
"repository": null,
"rust_version": null,
"source": null,
"targets": [
{
"crate_types": [
"lib"
],
"doc": true,
"doctest": true,
"edition": "2015",
"kind": [
"lib"
],
"name": "bar",
"src_path": "[..]/foo/bar/src/lib.rs",
"test": true
},
{
"crate_types": [
"bin"
],
"doc": false,
"doctest": false,
"edition": "2015",
"kind": [
"custom-build"
],
"name": "build-script-build",
"src_path": "[..]/foo/bar/build.rs",
"test": false
}
],
"version": "0.5.0"
},
{
"authors": [],
"categories": [],
"default_run": null,
"dependencies": [],
"description": null,
"documentation": null,
"edition": "2015",
"features": {},
"homepage": null,
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/bin-only-artifact#0.5.0",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]/foo/bin-only-artifact/Cargo.toml",
"metadata": null,
"name": "bin-only-artifact",
"publish": null,
"readme": null,
"repository": null,
"rust_version": null,
"source": null,
"targets": [
{
"crate_types": [
"bin"
],
"doc": true,
"doctest": false,
"edition": "2015",
"kind": [
"bin"
],
"name": "a-name",
"src_path": "[..]/foo/bin-only-artifact/src/main.rs",
"test": true
},
{
"crate_types": [
"bin"
],
"doc": true,
"doctest": false,
"edition": "2015",
"kind": [
"bin"
],
"name": "b-name",
"src_path": "[..]/foo/bin-only-artifact/src/main.rs",
"test": true
}
],
"version": "0.5.0"
},
{
"authors": [],
"categories": [],
"default_run": null,
"dependencies": [],
"description": null,
"documentation": null,
"edition": "2015",
"features": {},
"homepage": null,
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/non-artifact#0.5.0",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]/foo/non-artifact/Cargo.toml",
"metadata": null,
"name": "non-artifact",
"publish": null,
"readme": null,
"repository": null,
"rust_version": null,
"source": null,
"targets": [
{
"crate_types": [
"lib"
],
"doc": true,
"doctest": true,
"edition": "2015",
"kind": [
"lib"
],
"name": "non-artifact",
"src_path": "[..]/foo/non-artifact/src/lib.rs",
"test": true
}
],
"version": "0.5.0"
}
],
"resolve": {
"nodes": [
{
"dependencies": [],
"deps": [],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/artifact#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
},
{
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file://[..]/foo/artifact#0.5.0",
"path+file://[..]/foo/bin-only-artifact#0.5.0",
"path+file://[..]/foo/non-artifact#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
],
"deps": [
{
"dep_kinds": [
{
cargo-metadata: support -Zbindeps info
2023-01-06 17:00:55 +00:00
"extern_name": "artifact",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"kind": null,
"target": null
},
{
cargo-metadata: error out if same dep with differnt names Previous, `cargo metadata` allows a dependency with different renamed co-exist. However, its `resolve.nodes.deps` will miss that dependency, which is wrong. After this commit, `cargo metadata starts erroring out for that situation.
2023-01-10 01:02:09 +00:00
"artifact": "cdylib",
cargo-metadata: support -Zbindeps info
2023-01-06 17:00:55 +00:00
"compile_target": "wasm32-unknown-unknown",
cargo-metadata: error out if same dep with differnt names Previous, `cargo metadata` allows a dependency with different renamed co-exist. However, its `resolve.nodes.deps` will miss that dependency, which is wrong. After this commit, `cargo metadata starts erroring out for that situation.
2023-01-10 01:02:09 +00:00
"extern_name": "artifact",
cargo-metadata: support -Zbindeps info
2023-01-06 17:00:55 +00:00
"kind": null,
"target": null
},
{
cargo-metadata: error out if same dep with differnt names Previous, `cargo metadata` allows a dependency with different renamed co-exist. However, its `resolve.nodes.deps` will miss that dependency, which is wrong. After this commit, `cargo metadata starts erroring out for that situation.
2023-01-10 01:02:09 +00:00
"artifact": "staticlib",
cargo-metadata: support -Zbindeps info
2023-01-06 17:00:55 +00:00
"compile_target": "wasm32-unknown-unknown",
"extern_name": "artifact",
"kind": null,
"target": null
},
{
cargo-metadata: error out if same dep with differnt names Previous, `cargo metadata` allows a dependency with different renamed co-exist. However, its `resolve.nodes.deps` will miss that dependency, which is wrong. After this commit, `cargo metadata starts erroring out for that situation.
2023-01-10 01:02:09 +00:00
"artifact": "bin",
"bin_name": "baz-name",
cargo-metadata: support -Zbindeps info
2023-01-06 17:00:55 +00:00
"compile_target": "wasm32-unknown-unknown",
cargo-metadata: error out if same dep with differnt names Previous, `cargo metadata` allows a dependency with different renamed co-exist. However, its `resolve.nodes.deps` will miss that dependency, which is wrong. After this commit, `cargo metadata starts erroring out for that situation.
2023-01-10 01:02:09 +00:00
"extern_name": "baz_name",
cargo-metadata: support -Zbindeps info
2023-01-06 17:00:55 +00:00
"kind": null,
"target": null
},
{
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"kind": "dev",
"target": null
},
{
cargo-metadata: support -Zbindeps info
2023-01-06 17:00:55 +00:00
"artifact": "bin",
"bin_name": "bar-name",
"compile_target": "<target>",
"extern_name": "bar_name",
"kind": "build",
"target": null
},
{
"artifact": "bin",
"bin_name": "baz-name",
"compile_target": "<target>",
"extern_name": "baz_name",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"kind": "build",
"target": null
}
],
"name": "artifact",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "path+file://[..]/foo/artifact#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
},
{
"dep_kinds": [
{
cargo-metadata: support -Zbindeps info
2023-01-06 17:00:55 +00:00
"artifact": "bin",
"bin_name": "a-name",
"extern_name": "a_name",
"kind": null,
"target": null
},
{
"artifact": "bin",
"bin_name": "b-name",
"extern_name": "b_name",
"kind": "dev",
"target": null
},
{
"artifact": "bin",
"bin_name": "a-name",
"compile_target": "wasm32-unknown-unknown",
"extern_name": "a_name",
"kind": "build",
"target": null
},
{
"artifact": "bin",
"bin_name": "b-name",
"compile_target": "wasm32-unknown-unknown",
"extern_name": "b_name",
"kind": "build",
"target": null
}
],
"name": "",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "path+file://[..]/foo/bin-only-artifact#0.5.0"
cargo-metadata: support -Zbindeps info
2023-01-06 17:00:55 +00:00
},
{
"dep_kinds": [
{
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"kind": null,
"target": null
},
{
"kind": "dev",
"target": null
},
{
"kind": "build",
"target": null
}
],
"name": "non_artifact",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "path+file://[..]/foo/non-artifact#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
}
],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/bar#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
},
{
"dependencies": [],
"deps": [],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/bin-only-artifact#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
},
{
"dependencies": [],
"deps": [],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/non-artifact#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
}
],
"root": null
},
"target_directory": "[..]/foo/target",
"version": 1,
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file://[..]/foo/bar#0.5.0",
"path+file://[..]/foo/artifact#0.5.0",
"path+file://[..]/foo/bin-only-artifact#0.5.0",
"path+file://[..]/foo/non-artifact#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file://[..]/foo/bar#0.5.0",
"path+file://[..]/foo/artifact#0.5.0",
"path+file://[..]/foo/bin-only-artifact#0.5.0",
"path+file://[..]/foo/non-artifact#0.5.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"workspace_root": "[..]/foo"
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
}
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
`cargo metadata` works with workspaces
2016-08-28 12:10:27 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn cargo_metadata_with_invalid_manifest() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project().file("Cargo.toml", "").build();
Introduce cargo metadata subcommand Most of the work was done by @dan-t in #1225 and by @winger in #1434 Fixes #2193
2015-12-05 00:22:54 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --format-version 1")
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
simplify tests remove RUNNING, COMPILING, ERROR, DOCUMENTING, FRESH and UPDATING constants
2016-05-11 16:55:43 +00:00
[ERROR] failed to parse manifest at `[..]`
Introduce cargo metadata subcommand Most of the work was done by @dan-t in #1225 and by @winger in #1434 Fixes #2193
2015-12-05 00:22:54 +00:00
Caused by:
cargo fmt
2018-03-14 15:17:44 +00:00
virtual manifests must be configured with [workspace]",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Add unit test for invalid authors, refactor name
2022-08-08 15:05:43 +00:00
#[cargo_test]
fn cargo_metadata_with_invalid_authors_field() {
let p = project()
.file("src/foo.rs", "")
.file(
"Cargo.toml",
r#"
[package]
authors = ""
"#,
)
.build();
p.cargo("metadata")
.with_status(101)
.with_stderr(
feat: Add `rustc` style errors for manifest parsing
2023-12-14 22:28:05 +00:00
r#"[ERROR] invalid type: string "", expected a vector of strings or workspace
--> Cargo.toml:3:27
|
3 | authors = ""
| ^^
|
"#,
Add unit test for invalid authors, refactor name
2022-08-08 15:05:43 +00:00
)
.run();
}
Improve errors for TOML fields that support workspace inheritance
2022-09-20 03:41:20 +00:00
#[cargo_test]
fn cargo_metadata_with_invalid_version_field() {
let p = project()
.file("src/foo.rs", "")
.file(
"Cargo.toml",
r#"
[package]
version = 1
"#,
)
.build();
p.cargo("metadata")
.with_status(101)
.with_stderr(
feat: Add `rustc` style errors for manifest parsing
2023-12-14 22:28:05 +00:00
"\
[ERROR] invalid type: integer `1`, expected SemVer version
--> Cargo.toml:3:27
|
3 | version = 1
| ^
|
",
Improve errors for TOML fields that support workspace inheritance
2022-09-20 03:41:20 +00:00
)
.run();
}
Add metadata test for invalid publish field
2022-09-20 13:34:58 +00:00
#[cargo_test]
fn cargo_metadata_with_invalid_publish_field() {
let p = project()
.file("src/foo.rs", "")
.file(
"Cargo.toml",
r#"
[package]
publish = "foo"
"#,
)
.build();
p.cargo("metadata")
.with_status(101)
.with_stderr(
feat: Add `rustc` style errors for manifest parsing
2023-12-14 22:28:05 +00:00
r#"[ERROR] invalid type: string "foo", expected a boolean, a vector of strings, or workspace
--> Cargo.toml:3:27
|
3 | publish = "foo"
| ^^^^^
|
"#,
Add metadata test for invalid publish field
2022-09-20 13:34:58 +00:00
)
.run();
}
cargo-metadata: error out when encountering invalid artifact kind syntax This refactor reuse the logic of `core::compiler::unit_dependencies::match_artifacts_kind_with_targets` to emit error if there is any syntax error in `ArtifactKind`. It also put `match_artifacts_kind_with_targets` to a better place `core::compiler::artifact`.
2023-01-06 21:56:49 +00:00
#[cargo_test]
fn cargo_metadata_with_invalid_artifact_deps() {
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.5.0"
[dependencies]
artifact = { path = "artifact", artifact = "bin:notfound" }
"#,
)
.file("src/lib.rs", "")
.file("artifact/Cargo.toml", &basic_bin_manifest("artifact"))
.file("artifact/src/main.rs", "fn main() {}")
.build();
p.cargo("metadata -Z bindeps")
.masquerade_as_nightly_cargo(&["bindeps"])
.with_status(101)
.with_stderr(
"\
[WARNING] please specify `--format-version` flag explicitly to avoid compatibility problems
[ERROR] dependency `artifact` in package `foo` requires a `bin:notfound` artifact to be present.",
)
.run();
}
cargo-metadata: error out if same dep with differnt names Previous, `cargo metadata` allows a dependency with different renamed co-exist. However, its `resolve.nodes.deps` will miss that dependency, which is wrong. After this commit, `cargo metadata starts erroring out for that situation.
2023-01-10 01:02:09 +00:00
#[cargo_test]
fn cargo_metadata_with_invalid_duplicate_renamed_deps() {
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.5.0"
[dependencies]
bar = { path = "bar" }
baz = { path = "bar", package = "bar" }
"#,
)
.file("src/lib.rs", "")
.file("bar/Cargo.toml", &basic_lib_manifest("bar"))
.file("bar/src/lib.rs", "")
.build();
p.cargo("metadata")
.with_status(101)
.with_stderr(
"\
[WARNING] please specify `--format-version` flag explicitly to avoid compatibility problems
[ERROR] the crate `foo v0.5.0 ([..])` depends on crate `bar v0.5.0 ([..])` multiple times with different names",
)
.run();
}
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
const MANIFEST_OUTPUT: &str = r#"
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
{
"packages": [{
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"authors": [
"wycats@example.com"
],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
"name":"foo",
"version":"0.5.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id":"path+file://[..]/foo#0.5.0",
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
"source":null,
"dependencies":[],
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"keywords": [],
cargo: add license and license_file to cargo metadata output
2016-09-25 21:57:51 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Metadata response now also contains package description.
2017-02-02 07:59:34 +00:00
"description": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
"targets":[{
"kind":["bin"],
Fixed tests
2017-02-08 15:15:06 +00:00
"crate_types":["bin"],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": false,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
"name":"foo",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path":"[..]/foo/src/foo.rs"
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
}],
"features":{},
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"manifest_path":"[..]Cargo.toml",
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"metadata": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"publish": null,
Added new metadata fields. `cargo metadata` should now include all of the non-optional suggested fields in the API guidelines (see section C-METADATA.)
2018-04-18 08:08:18 +00:00
"readme": null,
Fix tests
2020-10-01 09:22:49 +00:00
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
}],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"workspace_members": [ "path+file:[..]foo#0.5.0" ],
"workspace_default_members": [ "path+file:[..]foo#0.5.0" ],
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
"resolve": null,
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"target_directory": "[..]foo/target",
Add workspace root to metadata command. Fixes #4933
2018-01-13 19:51:36 +00:00
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
}"#;
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn cargo_metadata_no_deps_path_to_cargo_toml_relative() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
.file("Cargo.toml", &basic_bin_manifest("foo"))
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/foo.rs", &main_file(r#""i am foo""#, &[]))
.build();
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --no-deps --manifest-path foo/Cargo.toml")
.cwd(p.root().parent().unwrap())
.with_json(MANIFEST_OUTPUT)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn cargo_metadata_no_deps_path_to_cargo_toml_absolute() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
.file("Cargo.toml", &basic_bin_manifest("foo"))
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/foo.rs", &main_file(r#""i am foo""#, &[]))
.build();
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --no-deps --manifest-path")
.arg(p.root().join("Cargo.toml"))
.cwd(p.root().parent().unwrap())
.with_json(MANIFEST_OUTPUT)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn cargo_metadata_no_deps_path_to_cargo_toml_parent_relative() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
.file("Cargo.toml", &basic_bin_manifest("foo"))
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/foo.rs", &main_file(r#""i am foo""#, &[]))
.build();
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --no-deps --manifest-path foo")
.cwd(p.root().parent().unwrap())
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"[ERROR] the manifest-path must be \
a path to a Cargo.toml file",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn cargo_metadata_no_deps_path_to_cargo_toml_parent_absolute() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
.file("Cargo.toml", &basic_bin_manifest("foo"))
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/foo.rs", &main_file(r#""i am foo""#, &[]))
.build();
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --no-deps --manifest-path")
.arg(p.root())
.cwd(p.root().parent().unwrap())
.with_status(101)
.with_stderr(
cargo fmt
2018-03-14 15:17:44 +00:00
"[ERROR] the manifest-path must be \
a path to a Cargo.toml file",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
fn cargo_metadata_no_deps_cwd() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
.file("Cargo.toml", &basic_bin_manifest("foo"))
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/foo.rs", &main_file(r#""i am foo""#, &[]))
.build();
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --no-deps")
.with_json(MANIFEST_OUTPUT)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Fixed a breaking change and added tests for that case.
2017-02-11 08:21:02 +00:00
fn cargo_metadata_bad_version() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
.file("Cargo.toml", &basic_bin_manifest("foo"))
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.file("src/foo.rs", &main_file(r#""i am foo""#, &[]))
.build();
metadata: add --no-deps option The intention is to eventually deprecate `cargo read-manifest`
2016-02-05 00:56:49 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --no-deps --format-version 2")
.with_status(1)
.with_stderr_contains(
cargo fmt
2018-03-14 15:17:44 +00:00
"\
chore: reflect to clap updates
2023-01-13 18:26:29 +00:00
error: invalid value '2' for '--format-version <VERSION>'
refactor(cli): Upgrade to clap v4
2022-09-20 18:19:46 +00:00
[possible values: 1]
cargo fmt
2018-03-14 15:17:44 +00:00
",
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Remove the test! macro This isn't really necessary and we can do setup manually in a few cases and lazily do it in all the others.
2016-05-25 20:55:42 +00:00
}
Parse --features in `cargo metadata` the same This accidentally didn't accept space-separated features passed through `--features` as the logic for doing the splitting wasn't shared. Let's share it!
2016-10-07 16:50:29 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Parse --features in `cargo metadata` the same This accidentally didn't accept space-separated features passed through `--features` as the logic for doing the splitting wasn't shared. Let's share it!
2016-10-07 16:50:29 +00:00
fn multiple_features() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
cargo fmt
2018-03-14 15:17:44 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.1.0"
authors = []
Parse --features in `cargo metadata` the same This accidentally didn't accept space-separated features passed through `--features` as the logic for doing the splitting wasn't shared. Let's share it!
2016-10-07 16:50:29 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[features]
a = []
b = []
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "")
cargotest/support: remove internal mutability in favor of switching types Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project. is_build==false <-> ProjectBuilder is_build==true <-> Project Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project. The same goes for RepoBuilder. ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability. Signed-off-by: NODA, Kai <nodakai@gmail.com>
2017-07-22 03:12:21 +00:00
.build();
Parse --features in `cargo metadata` the same This accidentally didn't accept space-separated features passed through `--features` as the logic for doing the splitting wasn't shared. Let's share it!
2016-10-07 16:50:29 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --features").arg("a b").run();
Parse --features in `cargo metadata` the same This accidentally didn't accept space-separated features passed through `--features` as the logic for doing the splitting wasn't shared. Let's share it!
2016-10-07 16:50:29 +00:00
}
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
fn package_metadata() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.1.0"
authors = ["wycats@example.com"]
categories = ["database"]
keywords = ["database"]
readme = "README.md"
repository = "https://github.com/rust-lang/cargo"
Test that homepage/documentation values are properly propagated
2020-10-01 09:23:06 +00:00
homepage = "https://rust-lang.org"
documentation = "https://doc.rust-lang.org/stable/std/"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package.metadata.bar]
baz = "quux"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
Create README file so tests pass
2020-06-09 07:15:28 +00:00
.file("README.md", "")
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
.file("src/lib.rs", "")
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
.build();
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --no-deps")
.with_json(
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
r#"
{
"packages": [
{
Explicitly test for new package metadata fields
2018-04-18 08:16:50 +00:00
"authors": ["wycats@example.com"],
"categories": ["database"],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"name": "foo",
Explicitly test for new package metadata fields
2018-04-18 08:16:50 +00:00
"readme": "README.md",
"repository": "https://github.com/rust-lang/cargo",
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Test that homepage/documentation values are properly propagated
2020-10-01 09:23:06 +00:00
"homepage": "https://rust-lang.org",
"documentation": "https://doc.rust-lang.org/stable/std/",
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"version": "0.1.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.1.0",
Explicitly test for new package metadata fields
2018-04-18 08:16:50 +00:00
"keywords": ["database"],
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"source": null,
"dependencies": [],
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"edition": "2015",
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"description": null,
"targets": [
{
"kind": [ "lib" ],
"crate_types": [ "lib" ],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"edition": "2015",
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"name": "foo",
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"src_path": "[..]foo/src/lib.rs"
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
}
],
"features": {},
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"manifest_path": "[..]foo/Cargo.toml",
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"metadata": {
"bar": {
"baz": "quux"
}
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
},
"publish": null
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"workspace_members": ["[..]foo#0.1.0"],
"workspace_default_members": ["[..]foo#0.1.0"],
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"resolve": null,
"target_directory": "[..]foo/target",
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
}"#,
)
.run();
}
#[cargo_test]
fn package_publish() {
let p = project()
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.1.0"
authors = ["wycats@example.com"]
categories = ["database"]
keywords = ["database"]
readme = "README.md"
repository = "https://github.com/rust-lang/cargo"
publish = ["my-registry"]
"#,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
)
Create README file so tests pass
2020-06-09 07:15:28 +00:00
.file("README.md", "")
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
.file("src/lib.rs", "")
.build();
p.cargo("metadata --no-deps")
.with_json(
r#"
{
"packages": [
{
"authors": ["wycats@example.com"],
"categories": ["database"],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"name": "foo",
"readme": "README.md",
"repository": "https://github.com/rust-lang/cargo",
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"version": "0.1.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.1.0",
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"keywords": ["database"],
"source": null,
"dependencies": [],
"edition": "2015",
"license": null,
"license_file": null,
"links": null,
"description": null,
"targets": [
{
"kind": [ "lib" ],
"crate_types": [ "lib" ],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"edition": "2015",
"name": "foo",
"src_path": "[..]foo/src/lib.rs"
}
],
"features": {},
"manifest_path": "[..]foo/Cargo.toml",
"metadata": null,
"publish": ["my-registry"]
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"workspace_members": ["[..]foo#0.1.0"],
"workspace_default_members": ["[..]foo#0.1.0"],
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"resolve": null,
Drop the [/] test output macro
2018-08-02 09:18:48 +00:00
"target_directory": "[..]foo/target",
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
}"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
include package metadata in `cargo metadata` Fixes #4819.
2018-04-14 19:07:23 +00:00
}
fix #4746 and add test Signed-off-by: gibix <gibix@riseup.net>
2018-06-01 10:38:16 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
fix #4746 and add test Signed-off-by: gibix <gibix@riseup.net>
2018-06-01 10:38:16 +00:00
fn cargo_metadata_path_to_cargo_toml_project() {
Remove the argument from the `project` test support function By rewriting the tests, with rerast (https://github.com/google/rerast), to use the newly introduced "at" method. First I added the following temporary function to cargotest::support: pub fn project_foo() -> ProjectBuilder { project("foo") } Then I defined the following rewrite.rs: use cargotest::support::{ project, project_foo }; fn rule1(a: &'static str) { replace!(project("foo") => project_foo()); replace!(project(a) => project_foo().at(a)); } Then I ran rerast: cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs Finally I searched and replaced the references to project_foo with argument-less project (a little awkardly on macOS with a git clean). find tests -type f -exec sed -i -e 's/project_foo/project/g' {} + git clean -d tests
2018-07-20 11:47:47 +00:00
let p = project()
fix #4746 and add test Signed-off-by: gibix <gibix@riseup.net>
2018-06-01 10:38:16 +00:00
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[workspace]
members = ["bar"]
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("bar/Cargo.toml", &basic_lib_manifest("bar"))
fix #4746 and add test Signed-off-by: gibix <gibix@riseup.net>
2018-06-01 10:38:16 +00:00
.file("bar/src/lib.rs", "")
.build();
Collapse multiline ProcessBuilder::arg calls in tests .. by calling this a bunch of times: fastmod --multiline '\.cargo\("([^"]+)"\).[ ]+\.arg\("([^"]+)"\)' '.cargo("${1} ${2}")' tests/testsuite/
2018-08-18 14:12:15 +00:00
p.cargo("package --manifest-path")
fix #4746 and add test Signed-off-by: gibix <gibix@riseup.net>
2018-06-01 10:38:16 +00:00
.arg(p.root().join("bar/Cargo.toml"))
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
.cwd(p.root().parent().unwrap())
.run();
fix #4746 and add test Signed-off-by: gibix <gibix@riseup.net>
2018-06-01 10:38:16 +00:00
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata --manifest-path")
.arg(p.root().join("target/package/bar-0.5.0/Cargo.toml"))
.with_json(
r#"
fix #4746 and add test Signed-off-by: gibix <gibix@riseup.net>
2018-06-01 10:38:16 +00:00
{
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"packages": [
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
{
"authors": [
"wycats@example.com"
],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"dependencies": [],
"description": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"edition": "2015",
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]#bar@0.5.0",
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"keywords": [],
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"manifest_path": "[..]Cargo.toml",
"metadata": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"publish": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"name": "bar",
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"source": null,
"targets": [
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
{
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"doctest": true,
"test": true,
"edition": "2015",
"kind": [
"lib"
],
"name": "bar",
"src_path": "[..]src/lib.rs"
}
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
],
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"version": "0.5.0"
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
}
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
],
"resolve": {
"nodes": [
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
{
"dependencies": [],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"deps": [],
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]#bar@0.5.0"
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
}
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]#bar@0.5.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
},
"target_directory": "[..]",
"version": 1,
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]#bar@0.5.0"
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]#bar@0.5.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"workspace_root": "[..]",
"metadata": null
}
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
}
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
fn package_edition_2018() {
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
let p = project()
.file("src/lib.rs", "")
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.1.0"
authors = ["wycats@example.com"]
edition = "2018"
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.build();
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata")
.with_json(
Add edition field into target object in metadata as well
2018-07-31 22:29:48 +00:00
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
{
"packages": [
{
"authors": [
"wycats@example.com"
],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dependencies": [],
"description": null,
"edition": "2018",
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]#0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]Cargo.toml",
"metadata": null,
"publish": null,
"name": "foo",
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"source": null,
"targets": [
{
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"doctest": true,
"test": true,
"edition": "2018",
"kind": [
"lib"
],
"name": "foo",
"src_path": "[..]src/lib.rs"
}
],
Add test and update docs
2021-06-08 03:28:58 +00:00
"version": "0.1.0"
}
],
"resolve": {
"nodes": [
{
"dependencies": [],
"deps": [],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]#0.1.0"
Add test and update docs
2021-06-08 03:28:58 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]#0.1.0"
Add test and update docs
2021-06-08 03:28:58 +00:00
},
"target_directory": "[..]",
"version": 1,
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]#0.1.0"
Add test and update docs
2021-06-08 03:28:58 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]#0.1.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
Add test and update docs
2021-06-08 03:28:58 +00:00
"workspace_root": "[..]",
"metadata": null
}
"#,
)
.run();
}
#[cargo_test]
fn package_default_run() {
let p = project()
.file("src/lib.rs", "")
.file("src/bin/a.rs", r#"fn main() { println!("hello A"); }"#)
.file("src/bin/b.rs", r#"fn main() { println!("hello B"); }"#)
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Add test and update docs
2021-06-08 03:28:58 +00:00
name = "foo"
version = "0.1.0"
authors = ["wycats@example.com"]
edition = "2018"
default-run = "a"
"#,
)
.build();
Fix `package_default_run`. The output was checking the `targets`, whose order depends on the filesystem order. Instead of checking all the output, just check the one field this test is for.
2021-06-11 23:08:20 +00:00
let json = p.cargo("metadata").run_json();
assert_eq!(json["packages"][0]["default_run"], json!("a"));
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
}
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
#[cargo_test]
fn package_rust_version() {
let p = project()
.file("src/lib.rs", "")
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
name = "foo"
version = "0.1.0"
authors = ["wycats@example.com"]
edition = "2018"
rust-version = "1.56"
"#,
)
.build();
let json = p.cargo("metadata").run_json();
assert_eq!(json["packages"][0]["rust_version"], json!("1.56"));
}
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
#[cargo_test]
fn target_edition_2018() {
let p = project()
.file("src/lib.rs", "")
.file("src/main.rs", "")
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.1.0"
authors = ["wycats@example.com"]
edition = "2015"
[lib]
edition = "2018"
"#,
)
.build();
p.cargo("metadata")
.with_json(
r#"
{
"packages": [
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
{
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"authors": [
"wycats@example.com"
],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
"dependencies": [],
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"description": null,
"edition": "2015",
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]#0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]Cargo.toml",
"metadata": null,
"publish": null,
"name": "foo",
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"source": null,
"targets": [
{
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"doctest": true,
"test": true,
"edition": "2018",
"kind": [
"lib"
],
"name": "foo",
"src_path": "[..]src/lib.rs"
},
{
"crate_types": [
"bin"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"doctest": false,
"test": true,
"edition": "2015",
"kind": [
"bin"
],
"name": "foo",
"src_path": "[..]src/main.rs"
}
],
"version": "0.1.0"
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
}
],
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"resolve": {
"nodes": [
{
"dependencies": [],
"deps": [],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]#0.1.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]#0.1.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
},
"target_directory": "[..]",
"version": 1,
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]#0.1.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]#0.1.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"workspace_root": "[..]",
"metadata": null
}
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Add edition field into metadata. Since edition feature was introduced, external tools have to support this new feature. But cargo metadata doesn't provide info about package edition. This commit adds edition field to SerializedPackage struct to add the corresponding field into metadata output.
2018-07-30 22:08:16 +00:00
}
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
fn rename_dependency() {
Package::new("bar", "0.1.0").publish();
Package::new("bar", "0.2.0").publish();
let p = project()
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
name = "foo"
version = "0.0.1"
authors = []
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
bar = { version = "0.1.0" }
baz = { version = "0.2.0", package = "bar" }
"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.file("src/lib.rs", "extern crate bar; extern crate baz;")
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
.build();
Migrate from tests fom assert_that/execs to .run()
2018-08-28 09:20:03 +00:00
p.cargo("metadata")
.with_json(
r#"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
{
"packages": [
{
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"dependencies": [],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"description": null,
"edition": "2015",
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#bar@0.1.0",
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"keywords": [],
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"manifest_path": "[..]",
"metadata": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"publish": null,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"name": "bar",
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"source": "registry+https://github.com/rust-lang/crates.io-index",
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"targets": [
{
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"edition": "2015",
"kind": [
"lib"
],
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"name": "bar",
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"src_path": "[..]"
}
],
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"version": "0.1.0"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
},
{
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"dependencies": [],
"description": null,
"edition": "2015",
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#bar@0.2.0",
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"keywords": [],
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"manifest_path": "[..]",
"metadata": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"publish": null,
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"name": "bar",
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Use correct registry on tests/testsuite/metadata.rs
2018-12-10 22:10:43 +00:00
"source": "registry+https://github.com/rust-lang/crates.io-index",
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"targets": [
{
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"edition": "2015",
"kind": [
"lib"
],
"name": "bar",
"src_path": "[..]"
}
],
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"version": "0.2.0"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
},
{
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"dependencies": [
{
"features": [],
"kind": null,
"name": "bar",
"optional": false,
"rename": null,
"registry": null,
"req": "^0.1.0",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"target": null,
"uses_default_features": true
},
{
"features": [],
"kind": null,
"name": "bar",
"optional": false,
"rename": "baz",
"registry": null,
"req": "^0.2.0",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"target": null,
"uses_default_features": true
}
],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"description": null,
"edition": "2015",
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.0.1",
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"keywords": [],
"license": null,
"license_file": null,
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
"links": null,
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"manifest_path": "[..]",
"metadata": null,
Include the publish field in cargo-metadata output
2019-09-11 18:46:12 +00:00
"publish": null,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"name": "foo",
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"source": null,
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"targets": [
{
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add `doctest` field into metadata Some tools can support rust doctests (e.g. highlighting or launching). So it should be possible to find out if doctests are enabled for a target or not. This commit adds `doctest` field to `cargo metadata` output.
2019-05-17 15:33:53 +00:00
"doctest": true,
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"edition": "2015",
"kind": [
"lib"
],
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"name": "foo",
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"src_path": "[..]"
}
],
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
"version": "0.0.1"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
}
],
"resolve": {
"nodes": [
{
"dependencies": [],
"deps": [],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#bar@0.1.0"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
},
{
"dependencies": [],
"deps": [],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#bar@0.2.0"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
},
{
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"registry+https://github.com/rust-lang/crates.io-index#bar@0.1.0",
"registry+https://github.com/rust-lang/crates.io-index#bar@0.2.0"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
],
"deps": [
{
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"name": "bar",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#bar@0.1.0"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
},
{
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
],
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
"name": "baz",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#bar@0.2.0"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
}
],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.0.1"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "[..]foo#0.0.1"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
},
"target_directory": "[..]",
"version": 1,
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]foo#0.0.1"
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]foo#0.0.1"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]",
"metadata": null
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
}"#,
Format with `cargo fmt`
2018-12-08 11:19:47 +00:00
)
.run();
Add rename info to Cargo metadata Previously, `cargo metadata` exposed dependencies info as a graph of package id without any additional information on edges. However, we do want to add some data to edges, including for example, package renames and `cfg` info. Internally, the edges info is represented as a `Vec<Dependnecy>`. We could have exposed that directly, but that risks exposing and ossifying an implementation details. So instead we collapse a `Vec<Dependnecy>` to a single JSON object, which at the moment contains `id` and `rename` info only. It should be possible to add additional fields to that object backwards compatibly. Such representation does not correspond directly to any internal Cargo data structure, but hopefully it shouldn't be to hard to maintain. This representation also does not quite correspond to the "real world", where dependencies are between crate (cargo targets), and not packages. However, because each dep edge is a JSON object, adding a target filter should be possible, which would handle dev-, build-, and potential future bin-specific dependencies backwards-compatibly.
2018-08-07 09:37:29 +00:00
}
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
fn metadata_links() {
let p = project()
.file(
"Cargo.toml",
r#"
refactor(testsuite): Replace `[project]` with `[package]`
2022-09-22 19:50:54 +00:00
[package]
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
name = "foo"
version = "0.5.0"
links = "a"
"#,
)
.file("src/lib.rs", "")
.file("build.rs", "fn main() {}")
.build();
p.cargo("metadata")
$cargo fmt --all
2019-01-27 13:39:49 +00:00
.with_json(
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
{
"packages": [
{
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dependencies": [],
"description": null,
"edition": "2015",
"features": {},
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.5.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": "a",
"manifest_path": "[..]/foo/Cargo.toml",
"metadata": null,
"publish": null,
"name": "foo",
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"source": null,
"targets": [
{
"crate_types": [
"lib"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"doctest": true,
"test": true,
"edition": "2015",
"kind": [
"lib"
],
"name": "foo",
"src_path": "[..]/foo/src/lib.rs"
},
{
"crate_types": [
"bin"
],
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": false,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"doctest": false,
"test": false,
"edition": "2015",
"kind": [
"custom-build"
],
"name": "build-script-build",
"src_path": "[..]/foo/build.rs"
}
],
"version": "0.5.0"
}
],
"resolve": {
"nodes": [
{
"dependencies": [],
"deps": [],
"features": [],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.5.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "[..]foo#0.5.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
},
"target_directory": "[..]/foo/target",
"version": 1,
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]foo#0.5.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]foo#0.5.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"workspace_root": "[..]/foo",
"metadata": null
}
"#,
$cargo fmt --all
2019-01-27 13:39:49 +00:00
)
Add `links` to `cargo metadata`. This is needed for creating registry index entries.
2018-12-23 19:28:26 +00:00
.run()
}
cargo metadata: Don't show `null` deps. If a package has a dependency without a library target, the "name" field was showing up as null in `resolve.nodes.deps`. At this time (AFAIK), binary-only dependencies are always ignored. Instead of making users filter out this entry (or more commonly, crash), just don't include it.
2019-01-10 05:04:16 +00:00
Update #[test] attribute on all tests in the testsuite sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]') Manual fixes: * proc_macro::proc_macro_doctest
2019-06-05 18:52:53 +00:00
#[cargo_test]
cargo metadata: Don't show `null` deps. If a package has a dependency without a library target, the "name" field was showing up as null in `resolve.nodes.deps`. At this time (AFAIK), binary-only dependencies are always ignored. Instead of making users filter out this entry (or more commonly, crash), just don't include it.
2019-01-10 05:04:16 +00:00
fn deps_with_bin_only() {
let p = project()
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.1.0"
[dependencies]
bdep = { path = "bdep" }
"#,
cargo metadata: Don't show `null` deps. If a package has a dependency without a library target, the "name" field was showing up as null in `resolve.nodes.deps`. At this time (AFAIK), binary-only dependencies are always ignored. Instead of making users filter out this entry (or more commonly, crash), just don't include it.
2019-01-10 05:04:16 +00:00
)
.file("src/lib.rs", "")
.file("bdep/Cargo.toml", &basic_bin_manifest("bdep"))
.file("bdep/src/main.rs", "fn main() {}")
.build();
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
p.cargo("metadata")
.with_json(
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
{
"packages": [
{
"name": "foo",
"version": "0.1.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"license": null,
"license_file": null,
Make test happy
2021-06-07 06:59:44 +00:00
"description": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"source": null,
"dependencies": [
{
"name": "bdep",
"source": null,
"req": "*",
"kind": null,
"rename": null,
"optional": false,
"uses_default_features": true,
Oops
2020-12-18 22:53:29 +00:00
"path": "[..]/foo/bdep",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"features": [],
"target": null,
"registry": null
}
],
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "foo",
"src_path": "[..]/foo/src/lib.rs",
"edition": "2015",
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"doctest": true,
"test": true
}
],
"features": {},
"manifest_path": "[..]/foo/Cargo.toml",
"metadata": null,
"publish": null,
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"keywords": [],
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"edition": "2015",
"links": null
}
],
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]foo#0.1.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]foo#0.1.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"resolve": {
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dependencies": [],
"deps": [],
"features": []
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "[..]foo#0.1.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
},
"target_directory": "[..]/foo/target",
"version": 1,
"workspace_root": "[..]foo",
"metadata": null
}
"#,
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
)
.run();
cargo metadata: Don't show `null` deps. If a package has a dependency without a library target, the "name" field was showing up as null in `resolve.nodes.deps`. At this time (AFAIK), binary-only dependencies are always ignored. Instead of making users filter out this entry (or more commonly, crash), just don't include it.
2019-01-10 05:04:16 +00:00
}
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
#[cargo_test]
fn filter_platform() {
// Testing the --filter-platform flag.
Package::new("normal-dep", "0.0.1").publish();
Package::new("host-dep", "0.0.1").publish();
Package::new("alt-dep", "0.0.1").publish();
Package::new("cfg-dep", "0.0.1").publish();
Switch azure to macOS 10.15.
2020-02-08 02:02:52 +00:00
// Just needs to be a valid target that is different from host.
// Presumably nobody runs these tests on wasm. 🙃
let alt_target = "wasm32-unknown-unknown";
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
let host_target = rustc_host();
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
[package]
name = "foo"
version = "0.1.0"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
[dependencies]
normal-dep = "0.0.1"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
[target.{}.dependencies]
host-dep = "0.0.1"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
[target.{}.dependencies]
alt-dep = "0.0.1"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
[target.'cfg(foobar)'.dependencies]
cfg-dep = "0.0.1"
"#,
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
host_target, alt_target
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
),
)
.file("src/lib.rs", "")
.build();
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
let alt_dep = r#"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
{
"name": "alt-dep",
"version": "0.0.1",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#alt-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"license": null,
"license_file": null,
"description": null,
"source": "registry+https://github.com/rust-lang/crates.io-index",
"dependencies": [],
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "alt-dep",
"src_path": "[..]/alt-dep-0.0.1/src/lib.rs",
"edition": "2015",
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"doctest": true
}
],
"features": {},
"manifest_path": "[..]/alt-dep-0.0.1/Cargo.toml",
"metadata": null,
"publish": null,
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"keywords": [],
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"edition": "2015",
"links": null
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
}
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"#;
let cfg_dep = r#"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
{
"name": "cfg-dep",
"version": "0.0.1",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#cfg-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"license": null,
"license_file": null,
"description": null,
"source": "registry+https://github.com/rust-lang/crates.io-index",
"dependencies": [],
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "cfg-dep",
"src_path": "[..]/cfg-dep-0.0.1/src/lib.rs",
"edition": "2015",
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"doctest": true
}
],
"features": {},
"manifest_path": "[..]/cfg-dep-0.0.1/Cargo.toml",
"metadata": null,
"publish": null,
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"keywords": [],
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"edition": "2015",
"links": null
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
}
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"#;
let host_dep = r#"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
{
"name": "host-dep",
"version": "0.0.1",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"license": null,
"license_file": null,
"description": null,
"source": "registry+https://github.com/rust-lang/crates.io-index",
"dependencies": [],
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "host-dep",
"src_path": "[..]/host-dep-0.0.1/src/lib.rs",
"edition": "2015",
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"doctest": true
}
],
"features": {},
"manifest_path": "[..]/host-dep-0.0.1/Cargo.toml",
"metadata": null,
"publish": null,
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"keywords": [],
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"edition": "2015",
"links": null
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
}
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"#;
let normal_dep = r#"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
{
"name": "normal-dep",
"version": "0.0.1",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"license": null,
"license_file": null,
"description": null,
"source": "registry+https://github.com/rust-lang/crates.io-index",
"dependencies": [],
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "normal-dep",
"src_path": "[..]/normal-dep-0.0.1/src/lib.rs",
"edition": "2015",
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"doctest": true
}
],
"features": {},
"manifest_path": "[..]/normal-dep-0.0.1/Cargo.toml",
"metadata": null,
"publish": null,
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"keywords": [],
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"edition": "2015",
"links": null
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
}
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"#;
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
// The dependencies are stored in sorted order by target and then by name.
// Since the testsuite may run on different targets, this needs to be
// sorted before it can be compared.
let mut foo_deps = serde_json::json!([
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
{
"name": "normal-dep",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"req": "^0.0.1",
"kind": null,
"rename": null,
"optional": false,
"uses_default_features": true,
"features": [],
"target": null,
"registry": null
},
{
"name": "cfg-dep",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"req": "^0.0.1",
"kind": null,
"rename": null,
"optional": false,
"uses_default_features": true,
"features": [],
"target": "cfg(foobar)",
"registry": null
},
{
"name": "alt-dep",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"req": "^0.0.1",
"kind": null,
"rename": null,
"optional": false,
"uses_default_features": true,
"features": [],
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
"target": alt_target,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"registry": null
},
{
"name": "host-dep",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"req": "^0.0.1",
"kind": null,
"rename": null,
"optional": false,
"uses_default_features": true,
"features": [],
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
"target": host_target,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"registry": null
}
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
]);
foo_deps.as_array_mut().unwrap().sort_by(|a, b| {
// This really should be `rename`, but not needed here.
// Also, sorting on `name` isn't really necessary since this test
// only has one package per target, but leaving it here to be safe.
let a = (a["target"].as_str(), a["name"].as_str());
let b = (b["target"].as_str(), b["name"].as_str());
a.cmp(&b)
});
let foo = r#"
{
"name": "foo",
"version": "0.1.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.1.0",
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
"license": null,
"license_file": null,
"description": null,
"source": null,
"dependencies":
$FOO_DEPS,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "foo",
"src_path": "[..]/foo/src/lib.rs",
"edition": "2015",
Emit the `test` field in cargo metadata
2020-07-12 14:52:31 +00:00
"test": true,
Publish target's "doc" setting when emitting metadata Prior to this commit `cargo metadata` would not emit the value of a target's "doc" setting, used by `cargo doc` to determine whether documentation should be generated. However, this information is useful for machine programs interested in such targets, and the information is already made available on the internal representation of a target, so this commit just exposes that during target serialization for emit. cf https://github.com/deadlinks/cargo-deadlinks/issues/99
2020-11-18 01:54:17 +00:00
"doc": true,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"doctest": true
}
],
"features": {},
"manifest_path": "[..]/foo/Cargo.toml",
"metadata": null,
"publish": null,
"authors": [],
"categories": [],
add default_run to SerializedPackage Delete "default_run": null,
2021-06-07 06:17:34 +00:00
"default_run": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"keywords": [],
"readme": null,
"repository": null,
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
2021-10-08 17:00:39 +00:00
"rust_version": null,
Fix tests
2020-10-01 09:22:49 +00:00
"homepage": null,
"documentation": null,
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"edition": "2015",
"links": null
}
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"#
Switch azure to macOS 10.15.
2020-02-08 02:02:52 +00:00
.replace("$ALT_TRIPLE", alt_target)
fix clippy warnings fixes these clippy warnings: map_collect_result_unit needless_borrow needless_return into_iter_on_ref manual_flatten match_like_matches_macro bool_comparison
2021-04-02 10:30:36 +00:00
.replace("$HOST_TRIPLE", host_target)
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
.replace("$FOO_DEPS", &foo_deps.to_string());
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
Add tests for fixed metadata download behavior
2020-12-17 18:01:24 +00:00
// We're going to be checking that we don't download excessively,
// so we need to ensure that downloads will happen.
let clear = || {
cargo_home().join("registry/cache").rm_rf();
cargo_home().join("registry/src").rm_rf();
p.build_dir().rm_rf();
};
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
// Normal metadata, no filtering, returns *everything*.
p.cargo("metadata")
Add tests for fixed metadata download behavior
2020-12-17 18:01:24 +00:00
.with_stderr_unordered(
"\
[UPDATING] [..]
[WARNING] please specify `--format-version` flag explicitly to avoid compatibility problems
[DOWNLOADING] crates ...
[DOWNLOADED] normal-dep v0.0.1 [..]
[DOWNLOADED] host-dep v0.0.1 [..]
[DOWNLOADED] alt-dep v0.0.1 [..]
[DOWNLOADED] cfg-dep v0.0.1 [..]
",
)
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
.with_json(
&r#"
{
"packages": [
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
$ALT_DEP,
$CFG_DEP,
$FOO,
$HOST_DEP,
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
$NORMAL_DEP
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
],
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]foo#0.1.0"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file:[..]foo#0.1.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"resolve": {
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#alt-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#cfg-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.1.0",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"registry+https://github.com/rust-lang/crates.io-index#alt-dep@0.0.1",
"registry+https://github.com/rust-lang/crates.io-index#cfg-dep@0.0.1",
"registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
"registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
],
"deps": [
{
"name": "alt_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#alt-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": "$ALT_TRIPLE"
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
{
"name": "cfg_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#cfg-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": "cfg(foobar)"
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
{
"name": "host_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": "$HOST_TRIPLE"
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
{
"name": "normal_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
}
],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]foo#0.1.0"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
"target_directory": "[..]/foo/target",
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
}
"#
Switch azure to macOS 10.15.
2020-02-08 02:02:52 +00:00
.replace("$ALT_TRIPLE", alt_target)
fix clippy warnings fixes these clippy warnings: map_collect_result_unit needless_borrow needless_return into_iter_on_ref manual_flatten match_like_matches_macro bool_comparison
2021-04-02 10:30:36 +00:00
.replace("$HOST_TRIPLE", host_target)
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
.replace("$ALT_DEP", alt_dep)
.replace("$CFG_DEP", cfg_dep)
.replace("$HOST_DEP", host_dep)
.replace("$NORMAL_DEP", normal_dep)
.replace("$FOO", &foo),
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
)
.run();
Add tests for fixed metadata download behavior
2020-12-17 18:01:24 +00:00
clear();
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
// Filter on alternate, removes cfg and host.
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
p.cargo("metadata --filter-platform")
Switch azure to macOS 10.15.
2020-02-08 02:02:52 +00:00
.arg(alt_target)
Add tests for fixed metadata download behavior
2020-12-17 18:01:24 +00:00
.with_stderr_unordered(
"\
[WARNING] please specify `--format-version` flag explicitly to avoid compatibility problems
[DOWNLOADING] crates ...
[DOWNLOADED] normal-dep v0.0.1 [..]
[DOWNLOADED] host-dep v0.0.1 [..]
[DOWNLOADED] alt-dep v0.0.1 [..]
",
)
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
.with_json(
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
&r#"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
{
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"packages": [
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
$ALT_DEP,
$FOO,
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
$NORMAL_DEP
],
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"workspace_members": "{...}",
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": "{...}",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"resolve": {
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#alt-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.1.0",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"registry+https://github.com/rust-lang/crates.io-index#alt-dep@0.0.1",
"registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
],
"deps": [
{
"name": "alt_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#alt-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": "$ALT_TRIPLE"
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
{
"name": "normal_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
}
],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]foo#0.1.0"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
"target_directory": "[..]foo/target",
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]foo",
"metadata": null
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
}
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"#
Switch azure to macOS 10.15.
2020-02-08 02:02:52 +00:00
.replace("$ALT_TRIPLE", alt_target)
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
.replace("$ALT_DEP", alt_dep)
.replace("$NORMAL_DEP", normal_dep)
.replace("$FOO", &foo),
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
)
.run();
Add tests for fixed metadata download behavior
2020-12-17 18:01:24 +00:00
clear();
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
// Filter on host, removes alt and cfg.
p.cargo("metadata --filter-platform")
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
.arg(&host_target)
Add tests for fixed metadata download behavior
2020-12-17 18:01:24 +00:00
.with_stderr_unordered(
"\
[WARNING] please specify `--format-version` flag explicitly to avoid compatibility problems
[DOWNLOADING] crates ...
[DOWNLOADED] normal-dep v0.0.1 [..]
[DOWNLOADED] host-dep v0.0.1 [..]
",
)
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
.with_json(
&r#"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
{
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"packages": [
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
$FOO,
$HOST_DEP,
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
$NORMAL_DEP
],
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"workspace_members": "{...}",
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": "{...}",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"resolve": {
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]foo#0.1.0",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
"registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
],
"deps": [
{
"name": "host_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": "$HOST_TRIPLE"
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
{
"name": "normal_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
}
],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]foo#0.1.0"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
"target_directory": "[..]foo/target",
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]foo",
"metadata": null
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
}
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"#
fix clippy warnings fixes these clippy warnings: map_collect_result_unit needless_borrow needless_return into_iter_on_ref manual_flatten match_like_matches_macro bool_comparison
2021-04-02 10:30:36 +00:00
.replace("$HOST_TRIPLE", host_target)
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
.replace("$HOST_DEP", host_dep)
.replace("$NORMAL_DEP", normal_dep)
.replace("$FOO", &foo),
)
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
.run();
Add tests for fixed metadata download behavior
2020-12-17 18:01:24 +00:00
clear();
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
// Filter host with cfg, removes alt only
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
p.cargo("metadata --filter-platform")
Fix filter_platform to run on targets other than x86.
2021-03-08 15:54:01 +00:00
.arg(&host_target)
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
.env("RUSTFLAGS", "--cfg=foobar")
Add tests for fixed metadata download behavior
2020-12-17 18:01:24 +00:00
.with_stderr_unordered(
"\
[WARNING] please specify `--format-version` flag explicitly to avoid compatibility problems
[DOWNLOADING] crates ...
[DOWNLOADED] normal-dep v0.0.1 [..]
[DOWNLOADED] host-dep v0.0.1 [..]
[DOWNLOADED] cfg-dep v0.0.1 [..]
",
)
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
.with_json(
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
&r#"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
{
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"packages": [
Stop ignoring Array ordering Json comparison tests. Update tests to have sorted order.
2020-07-15 23:22:28 +00:00
$CFG_DEP,
$FOO,
$HOST_DEP,
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
$NORMAL_DEP
],
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"workspace_members": "{...}",
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": "{...}",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"resolve": {
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#cfg-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file:[..]/foo#0.1.0",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"registry+https://github.com/rust-lang/crates.io-index#cfg-dep@0.0.1",
"registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
"registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
],
"deps": [
{
"name": "cfg_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#cfg-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": "cfg(foobar)"
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
{
"name": "host_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": "$HOST_TRIPLE"
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
{
"name": "normal_dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1",
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
]
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
}
],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#host-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "registry+https://github.com/rust-lang/crates.io-index#normal-dep@0.0.1",
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
"dependencies": [],
"deps": [],
"features": []
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file:[..]/foo#0.1.0"
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
},
"target_directory": "[..]/foo/target",
"version": 1,
Add support for `workspace.metadata` table
2020-06-02 19:33:13 +00:00
"workspace_root": "[..]/foo",
"metadata": null
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
}
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
"#
fix clippy warnings fixes these clippy warnings: map_collect_result_unit needless_borrow needless_return into_iter_on_ref manual_flatten match_like_matches_macro bool_comparison
2021-04-02 10:30:36 +00:00
.replace("$HOST_TRIPLE", host_target)
Rewrite target filtering to filter the entire graph. This also removes the special `host` target.
2019-10-08 15:08:08 +00:00
.replace("$CFG_DEP", cfg_dep)
.replace("$HOST_DEP", host_dep)
.replace("$NORMAL_DEP", normal_dep)
.replace("$FOO", &foo),
Add --filter-platform to `cargo metadata`.
2019-09-18 00:17:29 +00:00
)
.run();
}
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
#[cargo_test]
fn dep_kinds() {
Package::new("bar", "0.1.0").publish();
Package::new("winapi", "0.1.0").publish();
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.1.0"
[dependencies]
bar = "0.1"
[dev-dependencies]
bar = "0.1"
[build-dependencies]
bar = "0.1"
[target.'cfg(windows)'.dependencies]
winapi = "0.1"
"#,
)
.file("src/lib.rs", "")
.build();
p.cargo("metadata")
.with_json(
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
{
"packages": "{...}",
"workspace_members": "{...}",
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": "{...}",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"target_directory": "{...}",
"version": 1,
"workspace_root": "{...}",
"metadata": null,
"resolve": {
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]#bar@0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dependencies": [],
"deps": [],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]foo#0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]#bar@0.1.0",
"[..]#winapi@0.1.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
],
"deps": [
{
"name": "bar",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "[..]#bar@0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
},
{
"kind": "dev",
"target": null
},
{
"kind": "build",
"target": null
}
]
},
{
"name": "winapi",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "[..]#winapi@0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dep_kinds": [
{
"kind": null,
"target": "cfg(windows)"
}
]
}
],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]#winapi@0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dependencies": [],
"deps": [],
"features": []
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "[..]foo#0.1.0"
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
}
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
}
"#,
Add kind/platform info to `cargo metadata`
2019-07-14 21:02:55 +00:00
)
.run();
}
Remove metadata dep_kinds duplicates.
2019-12-30 18:10:45 +00:00
#[cargo_test]
fn dep_kinds_workspace() {
// Check for bug with duplicate dep kinds in a workspace.
// If different members select different features for the same package,
// they show up multiple times in the resolver `deps`.
//
// Here:
// foo -> dep
// bar -> foo[feat1] -> dep
let p = project()
.file(
"Cargo.toml",
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[package]
name = "foo"
version = "0.1.0"
Remove metadata dep_kinds duplicates.
2019-12-30 18:10:45 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[features]
feat1 = []
Remove metadata dep_kinds duplicates.
2019-12-30 18:10:45 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[dependencies]
dep = { path="dep" }
Remove metadata dep_kinds duplicates.
2019-12-30 18:10:45 +00:00
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
[workspace]
members = ["bar"]
"#,
Remove metadata dep_kinds duplicates.
2019-12-30 18:10:45 +00:00
)
.file("src/lib.rs", "")
.file(
"bar/Cargo.toml",
r#"
[package]
name = "bar"
version = "0.1.0"
[dependencies]
foo = { path="..", features=["feat1"] }
"#,
)
.file("bar/src/lib.rs", "")
.file("dep/Cargo.toml", &basic_lib_manifest("dep"))
.file("dep/src/lib.rs", "")
.build();
p.cargo("metadata")
.with_json(
r#"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
{
"packages": "{...}",
"workspace_members": "{...}",
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": "{...}",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"target_directory": "[..]/foo/target",
"version": 1,
"workspace_root": "[..]/foo",
"metadata": null,
"resolve": {
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/bar#0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file://[..]/foo#0.1.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
],
"deps": [
{
"name": "foo",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "path+file://[..]/foo#0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
]
}
],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/dep#0.5.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dependencies": [],
"deps": [],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo#0.1.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file://[..]/foo/dep#0.5.0"
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
],
"deps": [
{
"name": "dep",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "path+file://[..]/foo/dep#0.5.0",
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
]
}
],
"features": [
"feat1"
]
}
],
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"root": "path+file://[..]/foo#0.1.0"
Remove metadata dep_kinds duplicates.
2019-12-30 18:10:45 +00:00
}
Normalize raw string indentation.
2020-09-27 00:59:58 +00:00
}
"#,
Remove metadata dep_kinds duplicates.
2019-12-30 18:10:45 +00:00
)
.run();
}
Don't panic when printing JSON with non-utf8 paths Before: λ cd \Xff/foo/ && cargo verify-project && cargo metadata {"success":"true"} warning: please specify `--format-version` flag explicitly to avoid compatibility problems thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("path contains invalid UTF-8 characters", line: 0, column: 0)', /rustc/a5a775e3f9e8043dad405e00aee0ae60882a7b71/src/tools/cargo/src/cargo/core/shell.rs:346:51 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace After: λ cd \Xff/foo/ && $cargo verify-project && $cargo metadata {"success":"true"} warning: please specify `--format-version` flag explicitly to avoid compatibility problems error: path contains invalid UTF-8 characters I am pretty sure that this has zero real-world impact, but the diff is small, so why not handle it?
2021-03-02 07:41:57 +00:00
// Creating non-utf8 path is an OS-specific pain, so let's run this only on
// linux, where arbitrary bytes work.
#[cfg(target_os = "linux")]
#[cargo_test]
fn cargo_metadata_non_utf8() {
use std::ffi::OsString;
use std::os::unix::ffi::OsStringExt;
use std::path::PathBuf;
let base = PathBuf::from(OsString::from_vec(vec![255]));
let p = project()
.no_manifest()
.file(base.join("./src/lib.rs"), "")
.file(base.join("./Cargo.toml"), &basic_lib_manifest("foo"))
.build();
p.cargo("metadata")
.cwd(p.root().join(base))
.arg("--format-version")
.arg("1")
.with_stderr("error: path contains invalid UTF-8 characters")
.with_status(101)
.run();
}
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
// TODO: Consider using this test instead of the version without the 'artifact' suffix or merge them because they should be pretty much the same.
#[cargo_test]
fn workspace_metadata_with_dependencies_no_deps_artifact() {
let p = project()
// NOTE that 'artifact' isn't mentioned in the workspace here, yet it shows up as member.
.file(
"Cargo.toml",
r#"
[workspace]
members = ["bar", "baz"]
"#,
)
.file(
"bar/Cargo.toml",
r#"
[package]
name = "bar"
version = "0.5.0"
authors = ["wycats@example.com"]
[dependencies]
baz = { path = "../baz/" }
baz-renamed = { path = "../baz/" }
artifact = { path = "../artifact/", artifact = "bin" }
"#,
)
.file("bar/src/lib.rs", "")
.file("baz/Cargo.toml", &basic_lib_manifest("baz"))
.file("baz/src/lib.rs", "")
.file("artifact/Cargo.toml", &basic_bin_manifest("artifact"))
.file("artifact/src/main.rs", "fn main() {}")
.build();
p.cargo("metadata --no-deps -Z bindeps")
add a reason to `masquerade_as_nightly_cargo` so it is searchable
2022-07-16 02:32:23 +00:00
.masquerade_as_nightly_cargo(&["bindeps"])
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
.with_json(
r#"
{
"metadata": null,
"packages": [
{
"authors": [
"wycats@example.com"
],
"categories": [],
"default_run": null,
"dependencies": [
{
"artifact": {
"kinds": [
"bin"
],
"lib": false,
"target": null
},
"features": [],
"kind": null,
"name": "artifact",
"optional": false,
"path": "[..]/foo/artifact",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"features": [],
"kind": null,
"name": "baz",
"optional": false,
"path": "[..]/foo/baz",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
},
{
"features": [],
"kind": null,
"name": "baz-renamed",
"optional": false,
"path": "[..]/foo/baz",
"registry": null,
"rename": null,
"req": "*",
"source": null,
"target": null,
"uses_default_features": true
}
],
"description": null,
"documentation": null,
"edition": "2015",
"features": {},
"homepage": null,
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/bar#0.5.0",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]/foo/bar/Cargo.toml",
"metadata": null,
"name": "bar",
"publish": null,
"readme": null,
"repository": null,
"rust_version": null,
"source": null,
"targets": [
{
"crate_types": [
"lib"
],
"doc": true,
"doctest": true,
"edition": "2015",
"kind": [
"lib"
],
"name": "bar",
"src_path": "[..]/foo/bar/src/lib.rs",
"test": true
}
],
"version": "0.5.0"
},
{
"authors": [
"wycats@example.com"
],
"categories": [],
"default_run": null,
"dependencies": [],
"description": null,
"documentation": null,
"edition": "2015",
"features": {},
"homepage": null,
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/artifact#0.5.0",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]/foo/artifact/Cargo.toml",
"metadata": null,
"name": "artifact",
"publish": null,
"readme": null,
"repository": null,
"rust_version": null,
"source": null,
"targets": [
{
"crate_types": [
"bin"
],
"doc": true,
"doctest": false,
"edition": "2015",
"kind": [
"bin"
],
"name": "artifact",
"src_path": "[..]/foo/artifact/src/main.rs",
"test": true
}
],
"version": "0.5.0"
},
{
"authors": [
"wycats@example.com"
],
"categories": [],
"default_run": null,
"dependencies": [],
"description": null,
"documentation": null,
"edition": "2015",
"features": {},
"homepage": null,
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "path+file://[..]/foo/baz#0.5.0",
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"keywords": [],
"license": null,
"license_file": null,
"links": null,
"manifest_path": "[..]/foo/baz/Cargo.toml",
"metadata": null,
"name": "baz",
"publish": null,
"readme": null,
"repository": null,
"rust_version": null,
"source": null,
"targets": [
{
"crate_types": [
"lib"
],
"doc": true,
"doctest": true,
"edition": "2015",
"kind": [
"lib"
],
"name": "baz",
"src_path": "[..]/foo/baz/src/lib.rs",
"test": true
}
],
"version": "0.5.0"
}
],
"resolve": null,
"target_directory": "[..]/foo/target",
"version": 1,
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file://[..]/foo/bar#0.5.0",
"path+file://[..]/foo/artifact#0.5.0",
"path+file://[..]/foo/baz#0.5.0"
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
],
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"path+file://[..]/foo/bar#0.5.0",
"path+file://[..]/foo/artifact#0.5.0",
"path+file://[..]/foo/baz#0.5.0"
Added workspace_default_members to more tests.
2023-05-03 08:37:37 +00:00
],
add support for artifact dependencies (#9096) Tracking issue: https://github.com/rust-lang/cargo/issues/9096 Original PR: https://github.com/rust-lang/cargo/pull/9992 Add 'bindeps' -Z flag for later use A test to validate artifact dependencies aren't currently parsed. Parse 'artifact' and 'lib' fields. Note that this isn't behind a feature toggle so 'unused' messages will disappear. Transfer artifact dependencies from toml- into manifest-dependencies There are a few premises governing the operation. - if unstable features are not set, warn when 'artifact' or 'lib' is encountered. - bail if 'lib' is encountered alone, but warn that this WOULD happen with nightly. - artifact parsing checks for all invariants, but some aren't tested. Assure serialization of 'artifact' and 'lib' fields produces suitable values during publishing This should be the only place were these fields matter and where a cargo manifest is actually produced. These are only for internal use, no user is typically going to see or edit them. Place all artifact dependency tests inta their own module This facilitates deduplication later and possibly redistribution into other modules if there is a better fit. Represent artifacts that are rust libraries as another ArtifactKind This is more consistent and probably simpler for later use. No need to reflect the TOML data structure. Add tests to assure only 'lib = true' artifact deps are documented RFC-3028 doesn't talk about documentation, but for lib=true it's clear what the desired behaviour should be. If an artifact isn't a library though, then for now, it's transparent, maybe. Many more tests, more documentation, mild `Artifact` refactor The latter seems to be a better fit for what being an artifact really means within cargo, as it literally turns being a library on or off, and thus only optionally becoming a normal library. refactor to prepare for artifact related checks Don't show a no-lib warning for artifact dependencies (with lib = false) Tests for more artifact dependency invariants These are merely a proof of concept to show that we are not in a position to actually figure out everything about artifacts right after resolution. However, the error message looks more like a fatal error and less like something that can happen with a more elaborate error message with causes. This might show that these kind of checks might be better done later right before trying to use the information for create compile units. Validate that artifact deps with lib=true still trigger no-lib warnings This triggers the same warning as before, for now without any customization to indicate it's an artifact dependency. Use warnings instead of errors ------------------------------ This avoids the kind of harsh end of compilation in favor of something that can be recovered from. Since warnings are annoying, users will probably avoid re-declaring artifact dependencies. Hook in artifact dependencies into build script runs Even though we would still have to see what happens if they have a lib as well. Is it built twice? Also ---- - fly-by refactor: fix typo; use ? in method returning option - Propagate artifact information into Units; put artifacts into place This means artifacts now have their own place in the 'artifact' directory and uplifts won't happen for them. - refactor and fix cippy suggestion - fix build after rebasing onto master Create directories when executing the job, and not when preparing it. also: Get CI to work on windows the easy way, for now. Set directories for artifact dependencies in build script runtimes Test remaining kinds of build-script runtime environment variables Also ---- - Fix windows tests, the quick way. - Try to fix windows assertions, and generalize them - Fix second test for windows, hopefully test for available library dependency in build scripts with lib = true probably generally exclude all artifact dependencies with lib=false. Pass renamed dep names along with unit deps to allow proper artifact env names Test for selective bin:<name> syntax, as well as binaries with dashes Test to assure dependency names are transformed correctly assure advertised binaries and directories are actually present This wouldn't be the case if dependencies are not setup correctly, for instance. Also ---- - make it easier to see actual values even on failure This should help figure out why on CI something fails that works locally no matter what. Turns out this is a race condition, with my machine being on the good side of it so it doesn't show in testing. Fortunately it still can be reproduced and easily tested for. - refactor test; the race condition is still present though - Force CI to pass here by avoiding checks triggering race. - Fix windows build, maybe? More tolerant is_file() checks to account for delay on CI This _should_ help CI to test for the presence which is better than not testing at all. This appears to be needed as the output file isn't ready/present in time for some reason. The root cause of this issue is unknown, but it's definitely a race as it rarely happens locally. When it happened, the file was always present after the run. Now we will learn if it is truly not present, ever, or if it's maybe something very else. Validate libs also don't see artifact dependencies as libraries with lib=false Also ---- - Add prelimiary test for validating build-time artifacts - Try to fix CI on gnu windows Which apparently generates paths similar to linux, but with .exe suffix. The current linux patterns should match that. - refactor Help sharing code across modules allow rustc to use artifact dep environment variables, but… …it needs some adjustments to actually setup the unit dependency graph with artifacts as well. Right now it will only setup dependencies for artifacts that are libs, but not the artifacts themselves, completely ignoring them when they are not libs. Make artifact dependencies available in main loop This is the commit message #2: ------------------------------ rough cut of support for artifact dependencies at build time… …which unfortunately already shows that the binary it is supposed to include is reproducibly not ready in time even though the path is correct and it's present right after the run. Could it be related to rmeta? This is the commit message #3: ------------------------------ Fix test expectations as failure is typical than the warning we had before… …and add some tolerance to existing test to avoid occasional failures. This doesn't change the issue that it also doens't work at all for libraries, which is nicely reproducable and hopefully helps to fix this issue. This is the commit message #4: ------------------------------ Probably the fix for the dependency issue in the scheduler This means that bin() targets are now properly added to the job graph to cause proper syncing, whereas previously apparently it would still schedule binaries, but somehow consider them rmeta and thus start their dependents too early, leading to races. This is the commit message #5: ------------------------------ Don't accidentally include non-gnu windows tests in gnu windows. Support cargo doc and cargo check The major changes here are… - always compile artifacts in build mode, as we literally want the build output, always, which the dependent might rely on being present. - share code between the rather similar looking paths for rustdoc and rustc. Make artifact messages appear more in line with cargo by using backticks Also: Add first test for static lib support in build scripts build-scripts with support for cdylib and staticlib - Fix windows msvc build No need to speculate why the staticlib has hashes in the name even though nothing else. staticlib and cdylib support for libraries test staticlib and cdylibs for rustdoc as well. Also catch a seemingly untested special case/warning about the lack of linkable items, which probably shouldn't be an issue for artifacts as they are not linkable in the traditional sense. more useful test for 'cargo check' `cargo check` isn't used very consistently in tests, so when we use it we should be sure to actually try to use an artifact based feature to gain some coverage. verify that multiple versions are allowed for artifact deps as well. also: remove redundant test This is the commit message #2: ------------------------------ Properly choose which dependencies take part in artifact handling Previously it would include them very generously without considering the compatible dependency types. This is the commit message #3: ------------------------------ a more complex test which includes dev-dependencies It also shows that doc-tests don't yet work as rustdoc is run outside of the system into which we integrate right now. It should be possible to write our environment variable configuration in terms of this 'finished compilation' though, hopefully with most code reused. This is the commit message #4: ------------------------------ A first stab at storing artifact environment variables for packages… …however, it seems like the key for this isn't necessarily correct under all circumstances. Maybe it should be something more specific, don't know. This is the commit message #5: ------------------------------ Adjust key for identifying units to Metadata This one is actually unique and feels much better. This is the commit message #6: ------------------------------ Attempt to make use of artifact environment information… …but fail as the metadata won't match as the doctest unit is, of course, its separate unit. Now I wonder if its possible to find the artifact units in question that have the metadata. Properly use metadata to use artifact environment variables in doctests This is the commit message #2: ------------------------------ Add test for resolver = "2" and build dependencies Interestingly the 'host-features' flag must be set (as is seemingly documented in the flags documentation as well), even though I am not quite sure if this is the 100% correct solution. Should it rather have an entry with this flag being false in its map? Probably not… but I am not quite certain. This is the commit message #3: ------------------------------ set most if not all tests to use resolver = "2" This allows to keep it working with the most recent version while allowing to quickly test with "1" as well (which thus far was working fine). All tests I could imagine (excluding target and profiles) are working now Crossplatform tests now run on architecture aarm64 as well. More stringent negative testing Fix incorrect handling of dependency directory computation Previously it would just 'hack' the deps-dir to become something very different for artifacts. This could easily be fixed by putting the logic for artifact output directories into the right spot. A test for cargo-tree to indicate artifacts aren't handled specifically Assure build-scripts can't access artifacts at build time Actual doc-tests with access to artifact env vars All relevant parsing of `target = [..]` Next step is to actually take it into consideration. A failing test for adjusting the target for build script artifacts using --target Check for unknown artifact target triple in a place that exists for a year The first test showing that `target="target"` deps seemingly work For now only tested for build scripts, but it won't be much different for non-build dependencies. build scripts accept custom targets unconditionally Support target setting for non-build dependencies This is the commit message #2: ------------------------------ Add doc-test cross compile related test Even though there is no artifact code specific to doc testing, it's worth to try testing it with different target settings to validate it still works despite doc tests having some special caseing around target settings. This is the commit message #3: ------------------------------ A test to validate profiles work as expected for build-deps and non-build deps No change is required to make this work and artifact dependencies 'just work' based on the typical rules of their non-artifact counterarts. This is the commit message #4: ------------------------------ Adjust `cargo metadata` to deal with artifact dependencies This commit was squashed and there is probably more that changed. This is the commit message #5: ------------------------------ Show bin-only artifacts in "resolve" of metadata as well. This is the commit message #6: ------------------------------ minor refactoring during research for RFC-3176 This will soon need to return multiple extern-name/dep-name pairs. This is the commit message #7: ------------------------------ See if opt-level 3 works on win-msvc in basic profile test for artifacts This is the same value as is used in the other test of the same name, which certainly runs on windows. This is the commit message #8: ------------------------------ refactor Assure the type for targets reflect that they cannot be the host target, which removes a few unreachable!() expressions. Put `root_unit_compile_kind` into `UnitFor` Previously that wasn't done because of the unused `all_values()` method which has now been deleted as its not being used anyomre. This allows for the root unit compile kind to be passed as originally intended, instead of working around the previous lack of extendability of UnitFor due to ::all_values(). This is also the basis for better/correct feature handling once feature resolution can be depending on the artifact target as well, resulting in another extension to UnitFor for that matter. Also ---- - Fix ordering Previously the re-created target_mode was used due to the reordering in code, and who knows what kind of effects that might have (despite the test suite being OK with it). Let's put it back in place. - Deactivate test with filename collision on MSVC until RFC-3176 lands Avoid clashes with binaries called 'artifact' by putting 'artifact/' into './deps/' This commit addresses review comment https://github.com/rust-lang/cargo/pull/9992#discussion_r772939834 Don't rely on operator precedence for boolean operations Now it should be clear that no matter what the first term is, if the unit is an artifact, we should enqueue it. Replace boolean and `/*artifact*/ <bool>` with `IsArtifact::(Yes/No)` fix `doc::doc_lib_false()` test It broke due to major breakage in the way dependencies are calculated. Now we differentiate between deps computation for docs and for building. Avoid testing for doctest cross-compilation message It seems to be present on my machine, but isn't on linux and it's probably better to leave it out entirely and focus on the portions of consecutive output that we want to see at least. A test to validate features are unified across libraries and those in artifact deps in the same target Allow aarch64 MacOS to crosscompile to an easily executable alternative target That way more tests can run locally. Support for feature resolution per target The implementation is taken directly from RFC-3176 and notably lacks the 'multidep' part. Doing this definitely has the benefit of making entirely clear 'what is what' and helps to greatly reduce the scope of RFC-3176 when it's rebuilt based on the latest RF-3028, what we are implementing right now. Also ---- - A test which prooves that artifact deps with different target don't have a feature namespace yet - Add a test to validate features are namespaced by target Previously it didn't work because it relies on resolver = "2". - 'cargo metadata' test to see how artifact-deps are presented - Missed an opportunity for using the newly introduced `PackageFeaturesKey` - Use a HashMap to store name->value relations for artifact environment variables This is semantically closer to what's intended. also: Remove a by now misleading comment Prevent resolver crash if `target = "target"` is encountered in non-build dependencies A warning was emitted before, now we also apply a fix. Previously the test didn't fail as it accidentally used the old resolver, which now has been removed. Abort in parsing stage if nightly flag is not set and 'artifact' is used There is no good reason to delay errors to a later stage when code tries to use artifacts via environment variables which are not present. Change wording of warning message into what's expected for an error message remove unnecessary `Result` in `collect()` call Improve logic to warn if dependencie are ignored due to missing libraries The improvement here is to trigger correctly if any dependency of a crate is potentially a library, without having an actual library target as part of the package specification. Due to artifact dependencies it's also possible to have a dependency to the same crate of the same version, hence the package name isn't necessarily a unique name anymore. Now the name of the actual dependency in the toml file is used to alleviate this. Various small changes for readability and consistency A failing test to validate artifacts work in published crates as well Originally this should have been a test to see target acquisition works but this more pressing issue surfaced instead. Make artifacts known to the registry data (backwards compatible) Now artifacts are serialized into the registry on publish (at least if this code is actually used in the real crates-io registry) which allows the resolve stage to contain artifact information. This seems to be in line with the idea to provide cargo with all information it needs to do package resolution without downloading the actual manifest. Pick up all artifact targets into target info once resolve data is available Even though this works in the test at hand, it clearly shows there is a cyclic dependency between the resolve and the target data. In theory, one would have to repeat resolution until it settles while avoiding cycles. Maybe there is a better way. Add `bindeps`/artifact dependencies to `unstsable.md` with examples Fix tests Various small improvements Greatly simplify artifact environment propagation to commands Remove all adjustments to cargo-metadata, but leave tests The tests are to record the status quo with the current code when artifact dependencies are present and assure the information is not entirely non-sensical. Revert "Make artifacts known to the registry data (backwards compatible)" This reverts commit adc5f8ad04840af9fd06c964cfcdffb8c30769b0. Ideally we are able to make it work without altering the registry storage format. This could work if information from the package set is added to the resolve information. Enrich resolves information with additional information from downloaded manifests Resolve information comes from the registry, and it's only as rich as needed to know which packages take part in the build. Artifacts, however, don't influence dependency resolution, hence it shouldn't be part of it. For artifact information being present nonetheless when it matters, we port it back to the resolve graph where it will be needed later. Collect 'forced-target' information from non-workspace members as well This is needed as these targets aren't present in the registry and thus can't be picked up by traversing non-workspce members. The mechanism used to pick up artifact targets can also be used to pick up these targets. Remove unnecessary adjustment of doc test refactor `State::deps()` to have filter; re-enable accidentally disabled test The initial rebasing started out with a separted `deps_filtered()` method to retain the original capabilities while minimizing the chance for surprises. It turned out that the all changes combined in this PR make heavy use of filtering capabilities to the point where `deps(<without filter>)` was unused. This suggested that it's required to keep it as is without a way to inline portions of it. For the original change that triggered this rebase, see bd45ac81ba062a7daa3b0178dfcb6fd5759a943c The fix originally made was reapplied by allowing to re-use the required filter, but without inlining it. Always error on invalid artifact setup, with or without enabled bindeps feature Clarify how critical resolver code around artifact is working Remove workaround in favor of deferring a proper implementation See https://github.com/rust-lang/cargo/pull/9992#issuecomment-1033394197 for reference and the TODO in the ignored test for more information. truncate comments at 80-90c; cleanup - remove unused method - remove '-Z unstable-options' - improve error message - improve the way MSVC special cases are targetted in tests - improve how executables are found on non MSVC Avoid depending on output of rustc There is cyclic dependency between rustc and cargo which makes it impossible to adjust cargo's expectations on rustc without leaving broken commits in rustc and cargo. Add missing documentation fix incorrect removal of non-artifact libs This is also the first step towards cleaning up the filtering logic which is still making some logic harder to understand than needs be. The goal is to get it to be closer to what's currently on master. Another test was added to have more safety regarding the overall library inclusion logic. inline `build_artifact_requirements_to_units()` Simplify filtering This adds a default filter to `state.deps(…)` making it similar to what's currently in master, while creating another version of it to allow setting a custom filter. This is needed as the default filter won't allow build dependencies, which we need in this particular case. `calc_artifact_deps(…)` now hard-codes the default filter which is needed due to the use of `any` here: https://github.com/rust-lang/cargo/blob/c0e6abe384c2c6282bdd631e2f2a3b092043e6c6/src/cargo/core/compiler/unit_dependencies.rs#L1119 . Simplify filtering.
2021-10-21 09:57:23 +00:00
"workspace_root": "[..]/foo"
}
"#,
)
.run();
}
test(toml): Verify existing version-less behavior
2023-10-04 18:00:37 +00:00
#[cargo_test]
fn versionless_packages() {
let p = project()
.file(
"Cargo.toml",
r#"
[workspace]
members = ["bar", "baz"]
"#,
)
.file(
"bar/Cargo.toml",
r#"
[package]
name = "bar"
[dependencies]
foobar = "0.0.1"
baz = { path = "../baz/" }
"#,
)
.file("bar/src/lib.rs", "")
.file(
"baz/Cargo.toml",
r#"
[package]
name = "baz"
[dependencies]
foobar = "0.0.1"
"#,
)
.file("baz/src/lib.rs", "")
.build();
Package::new("foobar", "0.0.1").publish();
p.cargo("metadata -q --format-version 1")
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
.with_json(
r#"
{
"packages": [
{
"name": "bar",
"version": "0.0.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]bar#0.0.0",
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
"license": null,
"license_file": null,
"description": null,
"source": null,
"dependencies": [
{
"name": "baz",
"source": null,
"req": "*",
"kind": null,
"rename": null,
"optional": false,
"uses_default_features": true,
"features": [],
"target": null,
"registry": null,
"path": "[..]/baz"
},
{
"name": "foobar",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"req": "^0.0.1",
"kind": null,
"rename": null,
"optional": false,
"uses_default_features": true,
"features": [],
"target": null,
"registry": null
}
],
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "bar",
"src_path": "[..]/bar/src/lib.rs",
"edition": "2015",
"doc": true,
"doctest": true,
"test": true
}
],
"features": {},
"manifest_path": "[..]/bar/Cargo.toml",
"metadata": null,
"publish": [],
"authors": [],
"categories": [],
"keywords": [],
"readme": null,
"repository": null,
"homepage": null,
"documentation": null,
"edition": "2015",
"links": null,
"default_run": null,
"rust_version": null
},
{
"name": "baz",
"version": "0.0.0",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]baz#0.0.0",
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
"license": null,
"license_file": null,
"description": null,
"source": null,
"dependencies": [
{
"name": "foobar",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"req": "^0.0.1",
"kind": null,
"rename": null,
"optional": false,
"uses_default_features": true,
"features": [],
"target": null,
"registry": null
}
],
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "baz",
"src_path": "[..]/baz/src/lib.rs",
"edition": "2015",
"doc": true,
"doctest": true,
"test": true
}
],
"features": {},
"manifest_path": "[..]/baz/Cargo.toml",
"metadata": null,
"publish": [],
"authors": [],
"categories": [],
"keywords": [],
"readme": null,
"repository": null,
"homepage": null,
"documentation": null,
"edition": "2015",
"links": null,
"default_run": null,
"rust_version": null
},
{
"name": "foobar",
"version": "0.0.1",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]#foobar@0.0.1",
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
"license": null,
"license_file": null,
"description": null,
"source": "registry+https://github.com/rust-lang/crates.io-index",
"dependencies": [],
"targets": [
{
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "foobar",
"src_path": "[..]/foobar-0.0.1/src/lib.rs",
"edition": "2015",
"doc": true,
"doctest": true,
"test": true
}
],
"features": {},
"manifest_path": "[..]/foobar-0.0.1/Cargo.toml",
"metadata": null,
"publish": null,
"authors": [],
"categories": [],
"keywords": [],
"readme": null,
"repository": null,
"homepage": null,
"documentation": null,
"edition": "2015",
"links": null,
"default_run": null,
"rust_version": null
}
],
"workspace_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]bar#0.0.0",
"[..]baz#0.0.0"
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
],
"workspace_default_members": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]bar#0.0.0",
"[..]baz#0.0.0"
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
],
"resolve": {
"nodes": [
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]bar#0.0.0",
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]baz#0.0.0",
"[..]#foobar@0.0.1"
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
],
"deps": [
{
"name": "baz",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "[..]baz#0.0.0",
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
]
},
{
"name": "foobar",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "[..]#foobar@0.0.1",
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
]
}
],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]baz#0.0.0",
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
"dependencies": [
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"[..]#foobar@0.0.1"
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
],
"deps": [
{
"name": "foobar",
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"pkg": "[..]#foobar@0.0.1",
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
"dep_kinds": [
{
"kind": null,
"target": null
}
]
}
],
"features": []
},
{
refactor(metadata): Switch opaque ID from PackageID to PackageIDSpec
2023-11-02 16:37:14 +00:00
"id": "[..]#foobar@0.0.1",
feat(toml): Allow versionless packages This defaults the version to `0.0.0` for most of cargo. It is an error to lack a version and have a package publishable. That means you have to add `publish = false`.
2023-10-04 17:33:35 +00:00
"dependencies": [],
"deps": [],
"features": []
}
],
"root": null
},
"target_directory": "[..]/foo/target",
"version": 1,
"workspace_root": "[..]",
"metadata": null
}
test(toml): Verify existing version-less behavior
2023-10-04 18:00:37 +00:00
"#,
)
.run();
}
Reference in a new issue Copy permalink