Skip to content

parse linter config with cargo metadata #415

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

Closed
wants to merge 1 commit into from
Closed

Conversation

DaAlbrecht
Copy link
Collaborator

@DaAlbrecht DaAlbrecht commented May 7, 2025

Implementation for parsing out the linter config with cargo-metadata #334.

I personally prefer deserializing the Cargo.toml to toml and then parsing the metadata out over this. I can add some performance comparisons if needed, but I expect the cargo-metadata implementation to be way slower.

Some Observations:

  1. We need to create a linter config for each package that contains the workspace config (if present) merged with that package's config.

But the bevy_lint_driver is called for each crate target, meaning we could build the same config multiple times.

  1. Its "trickier" to get the metadata of the current package because we can not know that package's name.

In this repository: https://github.com/TimJentzsch/bevy_complex_repo/tree/main

❯ cargo metadata --no-deps | jq

lists all packages in this workspace, but from where do we know which of these we should read the metadata table from?

but with

 ❯ cargo metadata --format-version 1 | jq -r '
  .packages[] as $pkg
  | select($pkg.id == .resolve.root)
  | $pkg.name'
cplx_demo

We always get the "current" package but have additional overhead.

  1. The resulting code in the end is more or less identical, with the difference that in my opinion, toml is easier to work with for us and we need to depend on it anyway

@DaAlbrecht DaAlbrecht changed the title feat: parse linter config with cargo metadata parse linter config with cargo metadata May 7, 2025
@DaAlbrecht DaAlbrecht added A-Linter Related to the linter and custom lints X-Controversial There is active debate or serious implications around merging this PR labels May 7, 2025
@BD103
Copy link
Member

BD103 commented May 8, 2025

After skimming over the changes, I agree that this probably isn't worth it. While this does let us remove the dependency on toml, the added logical complexity isn't worth it in my opinion. Also, depending on how rust-lang/rfcs#3808 shapes up, we may still need to parse the TOML anyways for the time being. Thanks for trying this out!

@BD103 BD103 closed this May 8, 2025
@BD103 BD103 deleted the 334-cargo-metadata branch May 8, 2025 01:30
@DaAlbrecht
Copy link
Collaborator Author

After skimming over the changes, I agree that this probably isn't worth it. While this does let us remove the dependency on toml, the added logical complexity isn't worth it in my opinion. Also, depending on how rust-lang/rfcs#3808 shapes up, we may still need to parse the TOML anyways for the time being. Thanks for trying this out!

Yea and we need toml anyway for the cargo lint😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Linter Related to the linter and custom lints X-Controversial There is active debate or serious implications around merging this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants