feat: rust analysis support

[soul2zimate]

Description

feat: rust analysis support

Related issue (if any): https://issues.redhat.com/browse/TC-3459

Checklist

• I have followed this repository's contributing guidelines.
• I will adhere to the project's code of conduct.

Additional information

Assisted-by: Claude Code

[soul2zimate]

@ruromero please review when you have time.

[ruromero]

Thanks @soul2zimate
I have added a first round of comments. After you refactor and answer some of my questions I'd like to review again.

[ruromero]

Code Review

I have added 2 small suggestions.

Overall Design

After looking deeper in to how you addressed the problem I think it provides a great opportunity to introduce a complex but powerful feature for monorepo projects that we could consider adding to all the other package managers.

If I understood correctly your approach you resolve all the tree from the root down to the members but the dependencies are added to the root, meaning that
root.deps = [member1.dep1, member1.dep2, member2.dep3, ...]
That creates an incorrect SBOM because we don't know which deps each member has and it can be that different members introduce the same dep with different version or that a member depends on another member.
But we can use that to our benefit and consider the possibility to create a complex SBOM where we will have something like:

root
 member1
   dep1, dep2
 member2
   dep1, dep3
...

The stack analysis and generated SBOMs will be much detailed. We can also use the component analysis to underline the members with vulnerabilities.

Regarding the root name/version in virtual workspaces, we can use the folder name and set a placeholder version or the workspace.version if defined.

What do you think?

[ruromero]

I have reviewed the cargo metadata command execution because I think it doesn't need to use Threads.

Also I see that in general you're adding many unnecessary comments. This is not a good habit unless the code is simple but complex to understand. Try to avoid comments where the code is self-explanatory. I've commented some good / bad examples in your code.

[soul2zimate]

Thank you. I have updated to address the review on cargo metadata command execution, I will review and keep/remove comments in next upcoming workspace members hierarchical dependency processing commit

[soul2zimate]

I have fixed the workspace dependency processing, this now covers all three valid project structures as described below:

Crate Type	Component Analysis	Stack Analysis	Implementation Method
SINGLE_CRATE	Root crate's direct dependencies only	Root crate + all transitive dependencies	handleSingleCrate()
WORKSPACE_VIRTUAL	Dependencies from [workspace.dependencies] in TOML	All workspace members + their transitive dependencies	handleVirtualWorkspace()
WORKSPACE_WITH_ROOT_CRATE	Root crate's direct dependencies (workspace members only if actual deps)	Root crate + transitive dependencies (workspace members only if in root crate's dep graph)	handleSingleCrate()

[ruromero]

Only one concern about the error handling. The rest looks very nice and I think this will set some ground for more complex sbom generation.
Thanks

[ruromero]

Looks good, thanks!

[soul2zimate]

Merged. Thank you for the patient review