-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
do not process Cargo.lock for dependent crates, if parent has Cargo.lock #14906
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
98c28d0 to
2862f09
Compare
c18fe7f to
0d5516a
Compare
0d5516a to
fad86f6
Compare
fad86f6 to
f5f8120
Compare
f5f8120 to
4ccdc5c
Compare
e5e66db to
3194dc6
Compare
dcbaker
reviewed
Sep 24, 2025
These could also be target dependencies, which would fail the test in _add_dependency Extracted from a patch by Xavier Claessens <xclaessens@netflix.com>
This avoids cloning the same repo multiple times, instead a single wrap can provide multiple cargo dependencies.
3194dc6 to
6e91720
Compare
Do not create a single cargo.Interpreter for the whole execution, instead create one as soon as a Cargo.lock file is read and only make it last until that Cargo.lock has been processed. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Allow creating the cargo.Interpreter (and thus parsing the Cargo.lock file) even before 'rust' is added as a language. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When processing cargo subprojects, each Resolver was independently loading Cargo.lock files, leading to duplicate wraps and errors like 'Multiple wrap files provide dependency'. Instead, build the cargo.Interpreter as soon as a Cargo.lock file is found, and merge that Cargo.lock into the wrap resolver. There is no need anymore to build a separate resolver for the dependent packages, because their indirect dependencies are all listed in the parent lockfile.
This allows modifying the version number before the package is fetched. Extracted from a patch by Xavier Claessens <xclaessens@netflix.com>. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
While developing I often got a confusing 'Neither a subproject directory nor a None.wrap file was found'. Replace it with a clear message that explains: 1. Which dependency couldn't be found 2. What versions are available in the root Cargo.lock 3. That this is likely a version conflict 4. How to fix it (update dependencies to match root Cargo.lock) Example: ERROR: Dependency 'socket2-0.4-rs' not found. Root Cargo.lock provides: socket2-0.5-rs, socket2-0.6-rs. This could be a Meson bug, please report it. I am actually not sure if this is really always a Meson bug. But to be safe, suggest reporting it until more experience is gained. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
A dependency might specify a version that is compatible with the one in Cargo.lock, but not the exact same version. Whenever Cargo.lock contains the package, only use the pinned versions that can be used; update the version in the manifest so that the correct API level is used as well. Originally by Xavier Claessens <xclaessens@netflix.com>, but almost completely rewritten.
Extracted from a patch by Xavier Claessens <xclaessens@netflix.com>
6e91720 to
1aa7cff
Compare
dcbaker
approved these changes
Oct 14, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an important fix in the Cargo interpreter logic. The bug is that Meson will load a Cargo.lock per subproject; say you have:
Then Meson will obey subproject A's Cargo.lock to request syn 2, and subproject B's Cargo.lock to request syn 1. This is broken. Instead, Meson must take into account a single Cargo.lock per subproject invocation. It can come from the parent project, or from the requested subproject, but in any case there needs to be only one.
To fix this, this series:
(This is the first half of #14681)
Fixes: #14380
Fixes: #13335