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

Fix compat failures due to dependency updates (by honouring parent's dep versions) #111

Merged
merged 1 commit into from
Apr 23, 2024

Conversation

ijackson
Copy link
Contributor

Use Cargo.lock from workspace root (if available)

When using macrotest, to make output consistent, it is necessary to pin to a particular version of Nightly Rust.

But of course usptream Nightly Rust changes, and that means that dependencies (of the macro package under test) may need to be updated upstream. Sometimes those updates aren't compatible with our pinned Nightly.

Therefore, tests must run with pinned versions of the dependencies, not just pinned versions of the compiler. Without this, we can run into trouble, as seen here, for example:
https://gitlab.torproject.org/Diziet/rust-derive-deftly/-/issues/60

Borrow a trick from dtolnay's trybuild, which faces the same problem: copy the outer workspace's Cargo.lock into the synthetic crate. This influences Cargo's resolver sufficiently; but since we run without --locked, Cargo can still adjust the file as needed for the synthetic crate.

When using macrotest, to make output consistent, it is necessary to
pin to a particular version of Nightly Rust.

But of course usptream Nightly Rust changes, and that means that
dependencies (of the macro package under test) may need to be updated
upstream.  Sometimes those updates aren't compatible with our pinned
Nightly.

Therefore, tests must run with pinned versions of the dependencies,
not just pinned versions of the compiler.  Without this, we can run
into trouble, as seen here, for example:
  https://gitlab.torproject.org/Diziet/rust-derive-deftly/-/issues/60

Borrow a trick from dtolnay's trybuild, which faces the same problem:
copy the outer workspace's Cargo.lock into the synthetic crate.
This influences Cargo's resolver sufficiently; but since we run
without --locked, Cargo can still adjust the file as needed for the
synthetic crate.
Copy link
Collaborator

@taiki-e taiki-e left a comment

Choose a reason for hiding this comment

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

Thanks!

@taiki-e taiki-e merged commit 839a03e into eupn:master Apr 23, 2024
10 checks passed
@taiki-e
Copy link
Collaborator

taiki-e commented Apr 23, 2024

Published in 1.0.12.

@ijackson
Copy link
Contributor Author

❤️

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 this pull request may close these issues.

2 participants