5 ms·

I've always wondered why useful flags like `-Z timings` are not available on stable. I guess they're worried about the output changing in a future stable releas

I've always wondered why useful flags like `-Z timings` are not available on stable. I guess they're worried about the output changing in a future stable release, but I don't think anyone would expect the reports to look exactly the same and list exactly the same compilation phases, etc, for all eternity. I think that for diagnostic features, people would be just fine with a loose stability guarantee that allows the output to be improved in the future.

est31 5y ago
> I think that for diagnostic features, people would be just fine with a loose stability guarantee The issue with this is that the output might be parsed by downstream tools that assume a special format. They might break by a change in the output.
- spockz 5y ago
  It sounds like these tools should be using some machine format. Perhaps json or something as opposed to human readable strings. Then again, also the layout of the json might change but at least that can potentially be done in a backwards compatible manner.
JoshTriplett 5y ago
I've been working on stabilizing some options like this, with exactly that approach: the functionality is stable but the exact details aren't. For instance, instrument-coverage will work like that, generating coverage data that requires the current version of LLVM coverage tools to work with. timings doesn't seem especially hard to stabilize; I'll take a look at it.
- 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 ago
    https://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 ago
    I 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.
- pdimitar 5y ago
  It will be hugely appreciated, thank you. It's honestly annoying periodically checking the flags docs and wondering "these things don't seem to change much, when will we have them in stable?". As another poster down-thread said, human output can change at any time and this shouldn't be viewed as a stability problem. And if the machine output is still in the air then maybe it pays off to branch it out in a separate flag?
- JoshTriplett 5y ago
  PR to stabilize -Ztimings as --timings: https://github.com/rust-lang/cargo/pull/10245 https://github.com/rust-lang/cargo/pull/10245

est31 5y ago

> I think that for diagnostic features, people would be just fine with a loose stability guarantee The issue with this is that the output might be parsed by downstream tools that assume a special format. They might break by a change in the output.

spockz 5y ago
It sounds like these tools should be using some machine format. Perhaps json or something as opposed to human readable strings. Then again, also the layout of the json might change but at least that can potentially be done in a backwards compatible manner.

JoshTriplett 5y ago

I've been working on stabilizing some options like this, with exactly that approach: the functionality is stable but the exact details aren't. For instance, instrument-coverage will work like that, generating coverage data that requires the current version of LLVM coverage tools to work with. timings doesn't seem especially hard to stabilize; I'll take a look at it.

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 ago
  https://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 ago
  I 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.
pdimitar 5y ago
It will be hugely appreciated, thank you. It's honestly annoying periodically checking the flags docs and wondering "these things don't seem to change much, when will we have them in stable?". As another poster down-thread said, human output can change at any time and this shouldn't be viewed as a stability problem. And if the machine output is still in the air then maybe it pays off to branch it out in a separate flag?
JoshTriplett 5y ago
PR to stabilize -Ztimings as --timings: https://github.com/rust-lang/cargo/pull/10245 https://github.com/rust-lang/cargo/pull/10245