Closed wfchandler closed 1 month ago
This is what the rust big-brains came up with?
This is what the rust big-brains came up with?
No, I was just looking at what clippy
could do for us before going to the council of elders and saw these lints.
This is what the rust big-brains came up with?
No, I was just looking at what
clippy
could do for us before going to the council of elders and saw these lints.
Worth asking the council of elders? The _nopipe
suffix strikes me as inelegant.
Given https://github.com/oxidecomputer/oxide.rs/pull/774#issuecomment-2272135166 should we consider other approaches?
I brought this to the council of big brains going on vacation. There are a few possibilities, but given our need to support Windows I think the approach in this PR is best.
SIGPIPE
handler using the sigpipe crate. Ripgrep was doing this at one point, and we've done this in oxlog, but on Illumos using Rust < 1.82 this is not handled properly. More importantly, this does not work on non-Unix systems.print
macros at all; the approach taken in this PR. If you feel that the _nopipe
macros are too wordy, we could rename them to shadow the std
macros. The clippy bug is a bit of a pain, but we're aware of it now and I think it's reasonable to watch for it until the lint is fixed.Sounds like options 3 is the best option; and let's stay vigilant in code review given the clippy limitations.
With #746 we added the
_nopipe
variants of the(e)print(ln)!
macros to avoid panicking when piping to head(1). However, we do not systematically enforce their use, which will inevitably lead inconsistent usage within the project.Add
clippy
lints to ban use of the print macros in all non-test code. Either the_nopipe
variants should be used when we don't care if the input is read, orwrite!
when the information is crucial, such as an interactive session.