You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are there issues that block stabilization of the feature?
bump
I'd be very interested to have this stabilized.
Normalization formatting is a very important aspect of formatting. But not only for readability but especially for tools. For example, imagine a tool to test if the output of a proc. macro is correct, e.g. in case of https://docs.rs/synstructure/0.12.3/synstructure/macro.test_derive.html. It is best to first format both, actual and expected quotes and especially normalize them to make writing concrete expectation tests for these proc. macro tests less daunting. E.g. common problems is that you suffer while writing such tests because of missing or overflous , or other things that should have been normalized anyways since they do not really matter for the underlying macro expansion semantics.
I'd like to see this stabilised. When autogenerating source code, #[doc(...)] is a more predictable thing to emit, because it is not newline terminated. This means your codegen care emit zero newlines and care nothing about indentation. rustfmt can put that all back ... but currently you are still left with #[doc(...)] format comments and they are just less readable (to me at least) than /// comments.
Having this stabilised would allow codegen to use '#[doc(...)]` but humans not have to deal with it in the generated output.
Reacted by Robin Freyler, Trevor Gross, Kieran Kaelin, Zgarbul Andrey, Leonardo Gibrowski Faé and BioTomateDE
@burrbull thanks for linking that issue. Here's another I was able to find in the issue tracker (#4879). There may be other issues so it would be a great help if anyone who's interested in having this stabilized could track those down and cross link them here. Verifying whether old issues are unresolved or opening PRs for them also goes a long way if anyone has the bandwidth and interest!
Activity
[-][unstable option] unstable option: normalize_doc_attributes[/-][+][unstable option] normalize_doc_attributes[/+]burrbull commentedon Jul 27, 2019
Are there issues that block stabilization of the feature?
🧚♀️Normalize doc attributes into `///`
🧚♀️Normalize doc attributes into `///`
🧚♀️Normalize doc attributes into `///` (#17)
Robbepop commentedon Jun 5, 2020
bump
I'd be very interested to have this stabilized.
Normalization formatting is a very important aspect of formatting. But not only for readability but especially for tools. For example, imagine a tool to test if the output of a proc. macro is correct, e.g. in case of https://docs.rs/synstructure/0.12.3/synstructure/macro.test_derive.html. It is best to first format both, actual and expected quotes and especially normalize them to make writing concrete expectation tests for these proc. macro tests less daunting. E.g. common problems is that you suffer while writing such tests because of missing or overflous
,or other things that should have been normalized anyways since they do not really matter for the underlying macro expansion semantics.jonathanpallant commentedon May 24, 2022
I'd like to see this stabilised. When autogenerating source code,
#[doc(...)]is a more predictable thing to emit, because it is not newline terminated. This means your codegen care emit zero newlines and care nothing about indentation.rustfmtcan put that all back ... but currently you are still left with#[doc(...)]format comments and they are just less readable (to me at least) than///comments.Having this stabilised would allow codegen to use '#[doc(...)]` but humans not have to deal with it in the generated output.
burrbull commentedon May 24, 2022
#3988
ytmimi commentedon May 24, 2022
@jonathanpallant you can find more details about the configuration stabilization process here. We're not quite ready to stabilize this option just yet.
@burrbull thanks for linking that issue. Here's another I was able to find in the issue tracker (#4879). There may be other issues so it would be a great help if anyone who's interested in having this stabilized could track those down and cross link them here. Verifying whether old issues are unresolved or opening PRs for them also goes a long way if anyone has the bandwidth and interest!
normalize_doc_attributessometimes comments out code #3988