Fix Cargo version parsing for workspace inheritance syntax

[zahidblackduck]

JIRA Ticket

IDETECT-4925

Description

Both Cargo detectors were failing to parse name and version from Cargo projects using workspace inheritance syntax (version.workspace = true). For example, a valid Cargo.toml,

[workspace]
members = ["extra-lib"]
resolver = "2"

[workspace.package]
version = "0.5.0"
edition = "2021"
repository = "https://github.com/example/repo"

[package]
name = "root-app"
version.workspace = true
edition.workspace = true
repository.workspace = true

The CargoTomlParser was incorrectly assuming version to be a string, but in cases of workspace inheritance, version is represented as a toml table. This caused TomlInvalidTypeException during dependency extraction.

Proposed Fix:

• Updated CargoTomlParser to detect when version is a table and handle workspace inheritance correctly.
• Added unit tests to validate parsing of Cargo.toml files with version.workspace = true.

Note: This is meant to be shipped with detect 11.2 release.

[devmehtabd]

What do we want to do for conditions when versionObj is null, I have seen examples in python where version is not specified, do we have similar concept in Cargo?

[zahidblackduck]

That's an interesting question which I didn't think of earlier. I'll explore further whether there is any possibility of an version section being null and if so, then how cargo declares / handles this.

[zahidblackduck]

I have investigated further how cargo treats version field, and current behavior of the cargo detectors when version field is missing i.e. versionObj is null. I'm sharing my findings here,

Yes, versionObj can be null. The the version field has been optional in Cargo.toml since Cargo 1.75 (defaulting to 0.0.0 if omitted). [Reference]
However, the behavior differs based on project structure:

1. Projects Using Workspace Inheritance Syntax

Cargo CLI Detector:

• Depends on cargo tree command (introduced in Cargo 1.44)
• When version.workspace = true but workspace doesn't define version, cargo tree command fails
• The detector never reaches the CargoTomlParser logic
• Falls back to Cargo Lockfile Detector

Cargo Lockfile Detector:

• Successfully parses Cargo.toml even with null/missing version
• Defaults to "Default Detect Version" when version is null

Reference Doc

2. Standalone Projects (No Workspace)

Both Cargo CLI Detector and Cargo Lockfile Detector:

• Successfully parse Cargo.toml with null/missing version
• Both default to "Default Detect Version" when version is null
• cargo tree command succeeds even without an explicit version

So, the version field is required, when:

• Publishing to crates.io: Always required
• Workspace inheritance: Workspace must define the version (enforced by cargo tree)
• Local development: Optional since Cargo 1.75 (defaults to 0.0.0)

Conclusion
Our implementation of the current merge request safely handles null by returning Optional.of(new NameVersion(name, null)). When version is null, both detectors already default to "Default Detect Version"