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

features2 in index broke cargo backward compatibility #6135

Open
Turbo87 opened this issue Mar 2, 2023 · 1 comment · May be fixed by #6168
Open

features2 in index broke cargo backward compatibility #6135

Turbo87 opened this issue Mar 2, 2023 · 1 comment · May be fixed by #6168
Labels
A-backend ⚙️ C-bug 🐞 Category: unintended, undesired behavior

Comments

@Turbo87
Copy link
Member

Turbo87 commented Mar 2, 2023

Current Behavior

According to https://www.reddit.com/r/rust/comments/11348jp/comment/j8o4nn6/ ripgrep can no longer be built by older cargo versions (e.g. 1.13).

Expected Behavior

Older cargo versions should be able to still build ripgrep

Steps To Reproduce

according to the Reddit thread:

clone the ripgrep repo and run cargo +1.13.0 b --verbose

Environment

No response

Anything else?

We have identified that the issue is related to how we introduced features2 to the index. ripgrep appears to use clap and in v4.0.0-rc.1 clap started to use the dep: prefix, causing the index to use features2 field.

The way clap used it and crates.io split the features map into features and features2 resulted in the following:

{
  "features": {
    "unstable-doc": [
      "derive"
    ]
  },
  "features2": {
    "derive": [
      "dep:clap_derive",
      "dep:once_cell"
    ]
  }
}

You can see that the unstable-doc feature depends on the derive feature. But since derive is in features2 the old cargo version thinks that the feature does not exist.

When splitting the feature maps we should have recursively moved the unstable-doc feature to features2 too, because it depends on a feature which is itself in features2.

@Turbo87 Turbo87 added C-bug 🐞 Category: unintended, undesired behavior A-backend ⚙️ labels Mar 2, 2023
@Turbo87
Copy link
Member Author

Turbo87 commented Mar 9, 2023

After discussing this with the cargo team on Zulip, we decided that the easiest way forward is to move all features into feature2 if we detect that any feature uses the new feature syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-backend ⚙️ C-bug 🐞 Category: unintended, undesired behavior
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant