Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support dependencies from registries for artifact dependencies, take 2 #12421

Merged
merged 5 commits into from
Aug 25, 2023

Conversation

fee1-dead
Copy link
Member

This is a continuation of #12062, and closes #10405.

r? @ehuss

Here are things this PR changes:

  1. Add information about artifact dependencies to the index. This bumps index_v to 3 for people using bindeps.
  2. Make RustcTargetData mutable for the feature resolver. This is so that we can query rustc for target info as late as resolving features, as that is when we really know if a package is really going to be used.

@rustbot rustbot added A-cfg-expr Area: Platform cfg expressions A-crate-dependencies Area: [dependencies] of any kind A-dependency-resolution Area: dependency resolution and the resolver A-features2 Area: issues specifically related to the v2 feature resolver A-interacts-with-crates.io Area: interaction with registries A-manifest Area: Cargo.toml issues A-registries Area: registries A-testing-cargo-itself Area: cargo's tests Command-fetch Command-fix Command-metadata Command-publish Command-tree S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 31, 2023
@fee1-dead fee1-dead marked this pull request as draft July 31, 2023 14:31
@fee1-dead fee1-dead marked this pull request as ready for review July 31, 2023 17:31
@bors
Copy link
Collaborator

bors commented Aug 1, 2023

☔ The latest upstream changes (presumably #12426) made this pull request unmergeable. Please resolve the merge conflicts.

@ehuss
Copy link
Contributor

ehuss commented Aug 15, 2023

@fee1-dead Just wanted to check in and acknowledge that I have seen this PR, but I haven't had the time to look at it. I will try to get to it soon.

@@ -178,7 +178,7 @@ struct Summaries {
/// A lazily parsed [`IndexSummary`].
enum MaybeIndexSummary {
/// A summary which has not been parsed, The `start` and `end` are pointers
/// into [`Summaries::raw_data`] which this is an entry of.
/// into [`Summaries::raw_data`] which this isRegistryDependency an entry of.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a stray edit?

Suggested change
/// into [`Summaries::raw_data`] which this isRegistryDependency an entry of.
/// into [`Summaries::raw_data`] which this is an entry of.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

#[cargo_test]
#[ignore = "broken, need artifact info in index"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In targets_are_picked_up_from_non_workspace_artifact_deps, in the part that says Package::new("uses-artifact", "1.0.0"), can you add .schema_version(3) to make sure the index filtering is working correctly?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added

// and per-pkg-targets are not immediately known.
let mut activate_target = |target| {
self.target_data
.merge_compile_kind(CompileKind::Target(target))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this fails, it seems to generate a confusing error. See check_transitive_artifact_dependency_with_different_target. I think what would help is to add .with_context(|| format!("...")) with a message that says something like "failed to determine target information for target {target} for artifact dependency {name} in package {pkg_id}".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@@ -2894,8 +2896,7 @@ fn check_transitive_artifact_dependency_with_different_target() {
p.cargo("check -Z bindeps")
.masquerade_as_nightly_cargo(&["bindeps"])
.with_stderr_contains(
"error: could not find specification for target `custom-target`.\n \
Dependency `baz v0.0.0 [..]` requires to build for target `custom-target`.",
"error: failed to run `rustc` to learn about target-specific information",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error message seems pretty vague. I added a comment above to enhance in activate_target.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@@ -807,7 +815,7 @@ impl<'a> SummariesCache<'a> {
.get(..4)
.ok_or_else(|| anyhow::anyhow!("cache expected 4 bytes for index schema version"))?;
let index_v = u32::from_le_bytes(index_v_bytes.try_into().unwrap());
if index_v != INDEX_V_MAX {
if index_v != INDEX_V_MAX && index_v != 3 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you say more about why this check was added? It doesn't look like v3 is being written in SummariesCache::serialize anyway, so it is always 2.

I'm thinking this isn't necessary (yet), because older cargos don't fail to parse the new entries. The key part of this index check is IndexSummary::parse. If we make a change that causes that to fail, then older cargos will ignore those entries, and not place them in the cache (it assumes they are from a future format it does not understand). However, since bindeps is just adding new fields to the JSON, that doesn't cause a problem (new fields are ignored).

When we stabilize, I think we'll need to set INDEX_V_MAX to 3, but I'm not sure it is necessary to make any changes at this time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was simply carried over from the last PR. I don't remember my reasoning for this and I have removed this condition.

@ehuss
Copy link
Contributor

ehuss commented Aug 19, 2023

Thanks, this looks great!

Can you add a test to make sure the v index version filtering works? I think that would look like something like this:

Package::new("bar", "1.0.0").publish();
Package::new("bar", "1.0.1")
    .schema_version(3)
    .add_dep(dep.artifact("bin", Some(target.to_string())))
    .publish();

// Verify that without `-Zbindeps` that it does not use 1.0.1.
let p = project()
    .file("Cargo.toml",
        r#"
            [package]
            name = "foo"
            version = "0.1.0"

            [dependency]
            bar = "1.0"
        "#)
    .file("src/lib.rs", "")
    .build();

p.cargo("tree").with_stdout("...").run();

// And with -Zbindeps it can use 1.0.1.
p.cargo("update -Zbindeps").with_stderr("...").run();

// And without -Zbindeps, now that 1.0.1 is in Cargo.lock, it should fail.
p.cargo("check").with_status(101).with_stderr("...").run();

I think that should roughly cover it, but if you have other ideas on how to try to break it, I think it would be good to make sure that has plenty of coverage.


I noticed that this doesn't update download_accessible. Were there problems with that, or is that something that we can iterate on later? (Not a blocker for this PR.)


Related to download_accessible, I think FeatureResolver::is_proc_macro will panic if it needs to process a proc-macro loaded from an artifact dependency with a target, and there is some problem downloading (like a network error). That is, something like the following will panic:

#[cargo_test]
fn proc_macro_in_artifact_dep() {
    // Forcing FeatureResolver to check a proc-macro for a dependency behind a
    // target dependency.
    if cross_compile::disabled() {
        return;
    }
    Package::new("pm", "1.0.0")
        .file("src/lib.rs", "")
        .file(
            "Cargo.toml",
            r#"
                [package]
                name = "pm"
                version = "1.0.0"

                [lib]
                proc-macro = true

            "#,
        )
        .publish();
    let alternate = cross_compile::alternate();
    Package::new("bin-uses-pm", "1.0.0")
        .target_dep("pm", "1.0", alternate)
        .file("src/main.rs", "fn main() {}")
        .publish();
    // Simulate a network error downloading the proc-macro.
    std::fs::remove_file(cargo_test_support::paths::root().join("dl/pm/1.0.0/download")).unwrap();
    let p = project()
        .file(
            "Cargo.toml",
            &format!(
                r#"
                [package]
                name = "foo"
                version = "0.1.0"
                edition = "2021"

                [dependencies]
                bin-uses-pm = {{ version = "1.0", artifact = "bin", target = "{alternate}"}}
            "#
            ),
        )
        .file("src/lib.rs", "")
        .build();

    p.cargo("check -Z bindeps")
        .masquerade_as_nightly_cargo(&["bindeps"])
        .with_stderr("")
        .run();
}

Can you make sure to document IndexPackage::v with the new version 3 changes?

@fee1-dead fee1-dead force-pushed the bindeps-registry2 branch 2 times, most recently from df276af to 17b106b Compare August 19, 2023 04:52
@fee1-dead
Copy link
Member Author

Can you add a test to make sure the v index version filtering works?

added

I noticed that this doesn't update download_accessible. Were there problems with that, or is that something that we can iterate on later? (Not a blocker for this PR.)

Yeah, let's iterate on this later, I specifically did not look into updating download_accessible because it turned out to be a bit complicated for the last PR. I've added your test case as an ignored test.

Can you make sure to document IndexPackage::v with the new version 3 changes?

Yep, done.

@fee1-dead
Copy link
Member Author

not sure why check-version-bump is failing for cargo-credential. This PR doesn't modify that crate

@bors
Copy link
Collaborator

bors commented Aug 24, 2023

☔ The latest upstream changes (presumably #12381) made this pull request unmergeable. Please resolve the merge conflicts.

@ehuss
Copy link
Contributor

ehuss commented Aug 24, 2023

not sure why check-version-bump is failing for cargo-credential. This PR doesn't modify that crate

I think there was an issue that was since fixed (#12508).

@ehuss
Copy link
Contributor

ehuss commented Aug 24, 2023

Thanks, looks good! I appreciate you working on this.

I filed #12554 for the download_accessible issue, and #12555 to track updating crates.io (though I'm not sure when we should actually do that).

Can you resolve the merge conflict? Unfortunately it looks like I don't have permission to push to your branch.

@ehuss
Copy link
Contributor

ehuss commented Aug 25, 2023

Thanks!

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 25, 2023

📌 Commit 43dccc7 has been approved by ehuss

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 25, 2023
@bors
Copy link
Collaborator

bors commented Aug 25, 2023

⌛ Testing commit 43dccc7 with merge e2c6a3e...

@bors
Copy link
Collaborator

bors commented Aug 25, 2023

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing e2c6a3e to master...

@bors bors merged commit e2c6a3e into rust-lang:master Aug 25, 2023
20 checks passed
@fee1-dead fee1-dead deleted the bindeps-registry2 branch August 25, 2023 09:07
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 26, 2023
Update cargo

13 commits in 2cc50bc0b63ad20da193e002ba11d391af0104b7..925280f028db3a322935e040719a0754703947cf
2023-08-22 22:43:08 +0000 to 2023-08-25 21:16:44 +0000
- string leek is stable (rust-lang/cargo#12559)
- refactor: Pull out cargo-add MSRV code for reuse (rust-lang/cargo#12553)
- Contrib: Add process for security responses. (rust-lang/cargo#12487)
- Support dependencies from registries for artifact dependencies, take 2 (rust-lang/cargo#12421)
- fix(toml): Improve parse errors (rust-lang/cargo#12556)
- Create dedicated unstable flag for asymmetric-token (rust-lang/cargo#12551)
- chore(deps): update latest msrv to v1.72.0 (rust-lang/cargo#12549)
- changelog: add link to CVE-2023-40030 (rust-lang/cargo#12550)
- refactor(install): Move value parsing to clap (rust-lang/cargo#12547)
- fix: Set MSRV for internal packages (rust-lang/cargo#12381)
- doc: fix two links to tracing docs (rust-lang/cargo#12537)
- use AND search when having multiple terms (rust-lang/cargo#12548)
- fix(log): Use a more compact relative-time format (rust-lang/cargo#12542)

r? ghost
@ehuss ehuss added this to the 1.74.0 milestone Sep 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cfg-expr Area: Platform cfg expressions A-crate-dependencies Area: [dependencies] of any kind A-dependency-resolution Area: dependency resolution and the resolver A-features2 Area: issues specifically related to the v2 feature resolver A-interacts-with-crates.io Area: interaction with registries A-manifest Area: Cargo.toml issues A-registries Area: registries A-testing-cargo-itself Area: cargo's tests Command-fetch Command-fix Command-metadata Command-publish Command-tree S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

bindeps: Support registry dependencies
4 participants