Support running locally as a cargo subcommand
Closed this issue · 6 comments
One of the big things I've always wanted is a helper for doing a manual audit of panic-capable lines within my own codebase before making a release. (Sort of like how, with my more recent Python projects, I aim to have either fixed or whitelisted all static analyzer-reported code smells before making a release and then I put up a bunch of badges from sites like Scrutinizer and Codacy to show it.)
It'd really be helpful if I could type something like cargo list-panics and get a list of all the places in my codebase where I either panic! directly or call one of a customizable set of functions (eg. unwrap()), macros (eg. unimplemented!), and operators (eg. []) and which aren't defined in my codebase but are known to panic in the implementation being used.
(Essentially, I want to make sure my rapid prototyping phases don't leave any panics lying around in places which the release code actually can allow recovery from... and situations where harbor has a better memory for what builtins panic than I do.)
I think this is a great idea! Sounds like there are two things here, checking for panics, and running as a subcommand of cargo.
Yeah. I forgot to split them up.
Heck, I was so zoned out when I wrote it that I somehow edited away the whole bit I wanted to lead with about the utility of being able to generate a "list of the unsafe blocks to manually audit" readout from the command-line. (The panic-listing part was meant to be an "it would also lead nicely into proposal X" follow-up.)
@ssokolow I've refactored this project to be a cargo subcommand and published it to crates.io. Going to close this since I don't plan on implementing your suggestion of finding panics yet, but I do think it's a good idea if you wanted to contribute a pull request!
At the moment, I'm having trouble making time to do any programming at all because I'm still working to catch up to backlogged obligations which piled up while I was working on my degree project. (Even during my leisure breaks, I've got six months of LWN.net issues to catch up on.)
Given that I'm not sure I'll have time to work on that at any point in the near future, would you mind if I opened it up as a new issue in case someone else takes interest?
From what I remember of GitHub issues, only you or another project maintainer can set labels.