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

More update --breaking tests #14049

Merged
merged 4 commits into from
Jun 27, 2024
Merged

Conversation

torhovland
Copy link
Contributor

Related to #12425 (comment) in #12425.

@rustbot
Copy link
Collaborator

rustbot commented Jun 12, 2024

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 12, 2024
@torhovland
Copy link
Contributor Author

r? epage

@rustbot rustbot assigned epage and unassigned weihanglo Jun 12, 2024
@torhovland torhovland force-pushed the issue-12425-more-tests branch 2 times, most recently from 372ff8f to 7bdf956 Compare June 12, 2024 08:09
tests/testsuite/update.rs Outdated Show resolved Hide resolved
p.cargo("update -Zunstable-options --breaking [email protected]")
.masquerade_as_nightly_cargo(&["update-breaking"])
.with_stderr(
// FIXME: This is wrong.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I found another problem. We're not matching incompatible with [email protected].

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But maybe that's not a bug. Strictly speaking, 1.0.0 does not match the version requirement 1.0.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Anyway, I pushed a fix.

Copy link
Contributor

Choose a reason for hiding this comment

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

Think of this feature as a specially named --force flag. They identified the entry they want to update so we should.

What we also need a test for is if they specify a compatible version that isn't in the lockfile.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm actually not using the lock file. This should work whether or not there is a lock file. I'm just checking if the version matches the version req.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thats an implementation detail while I'm talking of user-facing semantics. We should match spec behavior with cargo update without --breaking.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Imagine a non-existing [email protected]. When run without a lock file, cargo update [email protected] does not complain. Then, if the same command is run again (now with a lock file), it complains about [email protected] not matching any packages. So it is not idempotent.

Is it OK if cargo update --breaking [email protected] also doesn't complain, whether or not there is a lock file?

If not OK, we'll have to query a previous_resolve just for this error message. And it might be a good idea to go back to reusing the ops::update_lockfile that the non-breaking update is running (but then having to make changes to keep). In any case, can we put that in a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@epage This may or may not be a task to put on the task list, but it depends on your answer to the question about cargo update --breaking [email protected] not complaining.

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's put it in the task list either way and not block this conversation further.

Copy link
Contributor Author

@torhovland torhovland Jun 27, 2024

Choose a reason for hiding this comment

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

Done.

FYI, this is changed in #14140. If there isn't a lock file, update -Zunstable-options --breaking [email protected] will do this:

[UPDATING] `dummy-registry` index
[LOCKING] 3 packages to latest compatible versions
[ADDING] incompatible v1.0.1 (latest: v2.0.0)

If there is a lock file, it will do this:

[ERROR] package ID specification `[email protected]` did not match any packages
Did you mean one of these?

  [email protected]

src/cargo/ops/cargo_update.rs Show resolved Hide resolved
tests/testsuite/update.rs Show resolved Hide resolved
@torhovland
Copy link
Contributor Author

@epage I found another bug, I think. See the latest commit: 901f78e

@epage
Copy link
Contributor

epage commented Jun 19, 2024

If I'm understanding, thats a question of whether non-workspace path dependencies should be affected by this (and whether we should error if nothing matched).

I think this makes a good case for erroring. Our mental model is this is a specialized force, so it makes sense the lockfile can update when others can't if we error.

As for local deps like this, we should make this a task in the tracking issue to verify the general approach of cargo wrt mutations (cargo add, cargo fix, etc).

@torhovland
Copy link
Contributor Author

Looks like this is actually consistent. We can not run cargo add on non-ws crates. When running cargo fix only ws members are being fixed. And cargo-edit also does not make upgrades in non-ws crates.

@torhovland
Copy link
Contributor Author

@epage I consider this PR ready on my part now. Awaiting further review comments.

@rustbot rustbot added the A-manifest Area: Cargo.toml issues label Jun 20, 2024
@weihanglo
Copy link
Member

While #14115 is not about bumping SemVer-breaking versions, this behavior described in #14115 (comment) could be a thing to consider supporting or adding a test: cargo update <pkg> --breaking shouldn't touch other unrelated packages from the same source.

tests/testsuite/update.rs Outdated Show resolved Hide resolved
tests/testsuite/update.rs Outdated Show resolved Hide resolved
Comment on lines 2425 to 2426
/// keyed on dependency name and source, we also need to know which manifest
/// files to update and which to keep unchanged, because they may be pinned or
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. this feels weird for the test to be prescriptive on the implementation in a comment
  2. This isn't right. Its not just files but individual dependencies. You could have renamed in one dependency block but not another

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I removed that part of the comment, moved the rest (updated) to the implementation, and added a test case for mixed pinning within the same manifest.

Copy link
Contributor

Choose a reason for hiding this comment

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

The comment removal was done in a later commit. Should it be done in the initial commit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

Comment on lines 2551 to 2552
let root_manifest = p.read_file("Cargo.toml");
let foo_manifest = p.read_file("foo/Cargo.toml");
let bar_manifest = p.read_file("bar/Cargo.toml");
let baz_manifest = p.read_file("baz/Cargo.toml");

assert_e2e().eq(
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Personally, I'd read next to use to keep knowledge as local as possible

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

Comment on lines 2552 to 2554
let foo_manifest = p.read_file("foo/Cargo.toml");
let bar_manifest = p.read_file("bar/Cargo.toml");
let baz_manifest = p.read_file("baz/Cargo.toml");
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it work to give these workspace members names tied to their role in the test? For example, they can be "pinned", "unpinned", "mixed-pinned". That'd make it easier to follow what the test is doing

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

@torhovland torhovland force-pushed the issue-12425-more-tests branch 2 times, most recently from e9fd85a to 5434977 Compare June 27, 2024 06:45
@torhovland
Copy link
Contributor Author

@epage Ready for review again.

@torhovland
Copy link
Contributor Author

@epage Sorry, my rebasing on master probably made the force push diff unreadable for you.

But all I changed was deleting that long comment in the test commit, and applying your suggestions here.

@epage
Copy link
Contributor

epage commented Jun 27, 2024

Thanks!

@bors r

@bors
Copy link
Collaborator

bors commented Jun 27, 2024

📌 Commit f41bdc1 has been approved by epage

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 Jun 27, 2024
@bors
Copy link
Collaborator

bors commented Jun 27, 2024

⌛ Testing commit f41bdc1 with merge 2607661...

.masquerade_as_nightly_cargo(&["update-breaking"])
.with_status(101)
.with_stderr_data(str![[r#"
[ERROR] expected a version like "1.32"
Copy link
Contributor

@epage epage Jun 27, 2024

Choose a reason for hiding this comment

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

Hadn't notice this before. This error message is bad. We should at least be calling out that we are parsing a package id spec

Existing behavior:

$ cargo update clap@foo
error: invalid package ID specification: `clap@foo`

Caused by:
  expected a version like "1.32"

(again, task is list is fine)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added.

@bors
Copy link
Collaborator

bors commented Jun 27, 2024

☀️ Test successful - checks-actions
Approved by: epage
Pushing 2607661 to master...

@bors bors merged commit 2607661 into rust-lang:master Jun 27, 2024
22 checks passed
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 3, 2024
Update cargo

23 commits in 4ed7bee47f7dd4416b36fada1909e9a62c546246..a515d463427b3912ec0365d106791f88c1c14e1b
2024-06-25 16:28:22  0000 to 2024-07-02 20:53:36  0000
- test: migrate rust_version and rustc* to snapbox (rust-lang/cargo#14177)
- test: mirgate fix* and future_incompat_report to snapbox (rust-lang/cargo#14173)
- test:migrate `edition/error` to snapbox (rust-lang/cargo#14175)
- chore(deps): update compatible (rust-lang/cargo#14174)
- refactor(source): Clean up after PathSource/RecursivePathSource split (rust-lang/cargo#14169)
- test: Migrate some files to snapbox (rust-lang/cargo#14132)
- test:  fix several assertions (rust-lang/cargo#14167)
- test: replace glob with explicit unordered calls (rust-lang/cargo#14166)
- Make it clear that `CARGO_CFG_TARGET_FAMILY` is multi-valued (rust-lang/cargo#14165)
- Document `CARGO_CFG_TARGET_ABI` (rust-lang/cargo#14164)
- test: Migrate git to snapbox (rust-lang/cargo#14159)
- test: migrate some files to snapbox (rust-lang/cargo#14158)
- test: migrate registry and registry_auth to snapbox (rust-lang/cargo#14149)
- gix: remove `revision` feature from cargo (rust-lang/cargo#14160)
- test: migrate package* and publish* to snapbox (rust-lang/cargo#14130)
- More `update --breaking` tests (rust-lang/cargo#14049)
- test: migrate clean to snapbox (rust-lang/cargo#14096)
- Allow `unexpected_builtin_cfgs` lint in `user_specific_cfgs` test (rust-lang/cargo#14153)
- test: migrate search, source_replacement and standard_lib to snapbox (rust-lang/cargo#14151)
- Docs: Update config summary to include missing keys. (rust-lang/cargo#14145)
- test: migrate `dep_info/diagnostics/direct_minimal_versions` to snapbox (rust-lang/cargo#14143)
- Docs: Remove duplicate `strip` section. (rust-lang/cargo#14146)
- Docs: Fix curly quotes in config docs. (rust-lang/cargo#14144)
@rustbot rustbot added this to the 1.81.0 milestone Jul 3, 2024
bors added a commit that referenced this pull request Jul 22, 2024
…te-breaking, r=weihanglo

Improved error message when `update --breaking` invalid spec.

Improves an error message when trying to do `cargo update --breaking clap@foo`:

```
- [ERROR] expected a version like "1.32"
  [ERROR] invalid package ID specification: `clap@foo`
  Caused by:
    expected a version like "1.32"
```

Related to #12425. Fixes an item [here](#12425 (comment)), as noted [here](#14049 (comment)).
bors added a commit that referenced this pull request Jul 22, 2024
…te-breaking, r=weihanglo

Improved error message when `update --breaking` invalid spec.

Improves an error message when trying to do `cargo update --breaking clap@foo`:

```
- [ERROR] expected a version like "1.32"
  [ERROR] invalid package ID specification: `clap@foo`
  Caused by:
    expected a version like "1.32"
```

Related to #12425. Fixes an item [here](#12425 (comment)), as noted [here](#14049 (comment)).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-manifest Area: Cargo.toml issues Command-update 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.

5 participants