Summary

A downstream project that depends only on the older published monty crate fails to compile after a fresh dependency resolution. Cargo selects the newer monty-types crate within the dependency range declared by monty, and the interpreter's exhaustive matches do not handle the added Complex variants. No interpreter API usage or Python input is needed to trigger the failure.

Runtime or environment

Affected published crate: monty 1.0.0 from crates.io, with monty-types 1.1.0 and monty-macros 1.1.0 selected by a fresh resolve. The registry entries were not yanked at the time of this check.
Toolchain: rustc 1.99.0, commit b940084d7eb6a299eb4bfeb8e34901bc051e7ac4, and Cargo 1.99.0, commit 5f94df478, on aarch64-apple-darwin.
Controls: the same older interpreter with monty-types 1.0.0 pinned; latest published monty 1.1.0; and the current main source at 591527397445bf734873252d1ee20c1b6308fe7f, also the v1.1.0 tag. All controls used the same toolchain and default features.

Steps to reproduce

Create a new directory with no Cargo.lock, the following Cargo.toml, and src/main.rs containing only fn main() {}.

[package]
name = "dependency-check"
version = "0.1.0"
edition = "2024"

[dependencies]
monty = "=1.0.0"

Run cargo check with the toolchain listed above. Inspect Cargo.lock or run cargo tree -i monty-types to confirm the selected shared-types version.
For the workaround control, add monty-types = "=1.0.0" under [dependencies], remove Cargo.lock, and run cargo check again. This control was executed in a separate project with otherwise identical input.

Expected behavior

The published interpreter should compile with dependencies that Cargo selects from its own declared version requirements. Cargo interprets the published [dependencies.monty-types] version = "1.0.0" as a caret requirement that accepts the newer minor release.

This reproduction depends only on the interpreter crate and uses none of the graph representation APIs that Monty documents as unstable. The expected result is successful compilation of the downstream project.

Actual behavior

The fresh resolve selects the affected combination listed above. cargo check exits with status 101 and two E0004 errors in the older interpreter's src/object_bridge.rs:

error[E0004]: non-exhaustive patterns: `&MontyType::Complex` not covered
    --> monty-1.0.0/src/object_bridge.rs:607:15
     |
 607 |         match self {
     |               ^^^^ pattern `&MontyType::Complex` not covered

error[E0004]: non-exhaustive patterns: `MontyNode::Complex(_)` not covered
    --> monty-1.0.0/src/object_bridge.rs:808:11
     |
 808 |     match node {
     |           ^^^^ pattern `MontyNode::Complex(_)` not covered

error: could not compile `monty` (lib) due to 2 previous errors

Adding the exact shared-types pin makes the older interpreter compile with exit status 0. Both the latest published interpreter and the main source control also compile with exit status 0. Those successful newer builds do not repair a fresh resolve that retains the older interpreter.

Evidence

Expected source: the affected published crate's normalized Cargo.toml, [dependencies.monty-types], declares version = "1.0.0"; the Cargo reference describes the accepted range in Version requirement syntax.
Failure source: executed cargo check runs of the exact downstream manifests above; the errors identify src/object_bridge.rs lines 607 and 808, with the new variants in the resolved shared-types crate's src/object.rs line 1218 and src/graph.rs line 74.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

The change that added these variants is PR #935, Add complex type. The published shared-types enum MontyType is exported as an ordinary public type, and the older interpreter also uses the graph enum internally. This report concerns the interpreter's dependency compatibility rather than a downstream consumer's use of unstable representations.

The separate declared Rust-version failure, #979, concerns compilation of the newer interpreter on older toolchains. The reproduction here runs on a toolchain where the newer interpreter passes and fails with enum exhaustiveness errors in the older interpreter.

Restoration check

Start with the downstream manifest above and no lockfile or direct shared-types pin. A fresh resolution from the public registry should produce a dependency combination that compiles on the measured toolchain. Keep the older interpreter dependency in this check so upgrading the interpreter does not mask the failure. The exact-pin control should continue to compile.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: Fresh dependency resolution blocks compilation for downstream projects that retain the affected older interpreter release. The failure occurs even in an otherwise empty project. Existing lockfiles selecting the older shared-types crate avoid this specific failure; other platforms were not tested.
Workaround status: available
Workaround basis: Adding the exact shared-types pin compiled successfully on the measured toolchain without changing the interpreter or application code. Upgrading the interpreter also compiled in the controls, but may require application changes and is not needed for the verified pin workaround.

Activity

No activity yet.