Option to ignore modules that cannot be resolved
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 7k
- Forks
- 1.1k
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 24
Description
Hi
I am working on async-stripe which generates rust files and run into frequent errors in my automatic CI pipeline when they (the upstream openapi) remove parts of the api surface, as those modules are still referenced in the manual written mod.rs files. The automatic codegen runs, rustfmt is applied, and it fails due to missing files.
Now, I could (and will in the mean time) just set the rustfmt step as optional and apply it manually as these cases need to be manually intercepted, but I would love it if that, rather than eagerly fail, there was an opt-in option to simply prune the modules that now no-longer exist such that it can recover and format the ones that do.
Formatting is then also checked in the subsequent PR that is generated, but it would be nice to have the PR be created with formatting applied at a best-effort level.
See https://github.com/arlyon/async-stripe/actions/runs/3493571680/jobs/5848542195
Cheers,
Alex
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the failure in the linked async-stripe CI run and inspect the manual mod.rs files referenced there. Trace how rustfmt handles unresolved module files and identify the option-parsing and module-discovery entry points. Done means an opt-in mode prunes missing modules and formats the remaining Rust files without failing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100