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

bug: Cargo.lock change does not cause re-cache #151

Closed
NobodyXu opened this issue Jun 26, 2023 · 1 comment · Fixed by #152
Closed

bug: Cargo.lock change does not cause re-cache #151

NobodyXu opened this issue Jun 26, 2023 · 1 comment · Fixed by #152

Comments

@NobodyXu
Copy link
Contributor

In cargo-binstall cargo-bins/cargo-binstall#1169 , I recently updated transitive dependencies in Cargo.lock, however rust-cache reuses the old cache with full-match.

I wonder if it could be some bugs in #147 or #148 , it seems very unlikely to be a hash collision of sha1.

@NobodyXu NobodyXu changed the title Potential bug due to #147 ? bug: Cargo.lock change does not cause re-cache Jun 26, 2023
@NobodyXu
Copy link
Contributor Author

I pretty much confirmed this since cargo-bins/cargo-binstall#1171 also changes Cargo.lock but rust-cache still uses the same cache with full-match.

This only happens with Cargo.lock, not Cargo.toml though.

Swatinem pushed a commit that referenced this issue Jun 27, 2023
Fixed #151

I've tried running manually load and parse `Cargo.lock` and it runs fine
until `sort_object` is called.

Since `Cargo.lock` is auto-generated and usually sorted, I think there
is no need for sorting.

Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant