Skip to content

Conversation

@bonzini
Copy link
Collaborator

@bonzini bonzini commented Aug 13, 2025

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:

  • subproject A requesting syn = "2"
  • subproject B requesting syn = '[">=1", "<3"]
  • subproject B with syn 1.0.x in its Cargo.lock file

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:

  • creates a cargo.Interpreter for each Cargo.lock file
  • keeps the CargoLock object in the cargo.Interpreter
  • for non-git subprojects, matches the versions available in the Cargo.lock file against the requirements in the Cargo.toml file that requests the dependency

(This is the first half of #14681)

Fixes: #14380

Fixes: #13335

@bonzini bonzini force-pushed the cargo-lock-for-1.10 branch from 98c28d0 to 2862f09 Compare August 13, 2025 15:22
@bonzini bonzini marked this pull request as ready for review August 13, 2025 15:23
@bonzini bonzini requested a review from jpakkane as a code owner August 13, 2025 15:23
@bonzini bonzini added language:rust subprojects/wraps dependencies:cargo Issues related to using cargo subprojects labels Aug 13, 2025
@bonzini bonzini added this to the 1.10 milestone Aug 13, 2025
@bonzini bonzini force-pushed the cargo-lock-for-1.10 branch 2 times, most recently from c18fe7f to 0d5516a Compare August 17, 2025 07:44
@bonzini bonzini force-pushed the cargo-lock-for-1.10 branch from 0d5516a to fad86f6 Compare August 19, 2025 23:52
@bonzini bonzini force-pushed the cargo-lock-for-1.10 branch from fad86f6 to f5f8120 Compare August 25, 2025 13:48
@bonzini bonzini force-pushed the cargo-lock-for-1.10 branch from f5f8120 to 4ccdc5c Compare September 12, 2025 11:56
@bonzini bonzini force-pushed the cargo-lock-for-1.10 branch 2 times, most recently from e5e66db to 3194dc6 Compare September 24, 2025 16:19
bonzini and others added 2 commits October 7, 2025 16:46
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.
@bonzini bonzini force-pushed the cargo-lock-for-1.10 branch from 3194dc6 to 6e91720 Compare October 7, 2025 14:46
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>
@bonzini bonzini force-pushed the cargo-lock-for-1.10 branch from 6e91720 to 1aa7cff Compare October 7, 2025 16:37
@dcbaker dcbaker merged commit 39ebb85 into mesonbuild:master Oct 14, 2025
33 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies:cargo Issues related to using cargo subprojects language:rust subprojects/wraps

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wrap module erroneously excludes folders if their name matches a Cargo crate consumed via Git rust: can't load cargo package with git source

3 participants