Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[unstable option] normalize_doc_attributes #3351

Open
scampi opened this issue Feb 13, 2019 · 5 comments
Open

[unstable option] normalize_doc_attributes #3351

scampi opened this issue Feb 13, 2019 · 5 comments
Labels
unstable option tracking issue of an unstable option
Milestone

Comments

@scampi
Copy link
Contributor

scampi commented Feb 13, 2019

Tracking issue for unstable option: normalize_doc_attributes

@scampi scampi added the unstable option tracking issue of an unstable option label Feb 13, 2019
@scampi scampi changed the title [unstable option] unstable option: normalize_doc_attributes [unstable option] normalize_doc_attributes Feb 18, 2019
@burrbull
Copy link

Are there issues that block stabilization of the feature?

idubrov pushed a commit to commure/sourcegen that referenced this issue Aug 21, 2019
Stable `rustfmt` does not support normalizing doc attributes: rust-lang/rustfmt#3351

So, we "normalize" them ourselves by rendering `///`.
idubrov pushed a commit to commure/sourcegen that referenced this issue Aug 21, 2019
Stable `rustfmt` does not support normalizing doc attributes: rust-lang/rustfmt#3351

So, we "normalize" them ourselves by rendering `///`.
idubrov pushed a commit to commure/sourcegen that referenced this issue Aug 21, 2019
Stable `rustfmt` does not support normalizing doc attributes: rust-lang/rustfmt#3351

So, we "normalize" them ourselves by rendering `///`.
@Robbepop
Copy link

Robbepop commented Jun 5, 2020

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.

@topecongiro topecongiro added this to the 2.1.0 milestone Jun 29, 2020
@jonathanpallant
Copy link

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.

@burrbull
Copy link

#3988

@ytmimi
Copy link
Contributor

ytmimi commented 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unstable option tracking issue of an unstable option
Projects
None yet
Development

No branches or pull requests

6 participants