4 ms·
But you can't just say that the flag is stable while the output may change. Third party tools might rely on the output. This is okay for things read by humans
by est31 5y ago
But you can't just say that the flag is stable while the output may change.
Third party tools might rely on the output. This is okay for things read by humans (say the error messages) but fails for things that tools are parsing, like data needed for code coverage tools. Stabilization of instrument-coverage, as proposed, is a bad idea in my opinion. I'm sad that the concerns have not been addressed: https://github.com/rust-lang/rust/pull/90132#issuecomment-949736508 https://github.com/rust-lang/rust/pull/90132#issuecomment-94...
- JoshTriplett 5y agohttps://github.com/rust-lang/rust/pull/90132#issuecomment-951510501 https://github.com/rust-lang/rust/pull/90132#issuecomment-95... It depends on whether what you're stabilizing is an output format or a set of functionality. I think it's reasonable to do the latter. (If you'd like to talk about that further, I would suggest Zulip.)
- howdydoo 5y agoI would expect the stability guarantee to cover outputting _something_ human-readable, and that's it. If you want to parse the output, I would scope that under a separate feature such as `-Z timings-json`. This is similar to error messages, where the colorized output and text can change at any time, but tools can pass a flag to get stable JSON output.