Try to solve issue 3417.

[xiongmao86]

Add two tests first for #3417. Close #3417.

[xiongmao86]

I don't know how to write this if block a better way, please give me suggestion.

[xiongmao86]

And I wonder how to select multiply lines in the commit view. please give me suggestion.

[xiongmao86]

Setting normalize_comments and wrap_comments to true no longer imply setting format_doc_comments. And I wonder should I change the option format_doc_comments to format_code_in_doc_comments or just change the description of the option?

[xiongmao86]

Travis CI build break because of rand crate has format_doc_comments in rustfmt.toml. What should I do next?

[scampi]

The code change looks good to me @xiongmao86

With the stability guaranty of rustfmt, we can't simply rename the option: rand's build failure is a good example. A possible solution would be to introduce the concept of options "aliases":

• an option, here format_doc_comments, can be used with another name, here format_code_in_doc_comments
• the first variant of the option's name would be marked as deprecated and removed in a major release.

@topecongiro What do you think of such a mechanism ? Just improving the format_doc_comments description could be enough for this issue, but I think a more obvious option's name would be good.

[RReverser]

With the stability guaranty of rustfmt, we can't simply rename the option

All of these are unstable options though, so I'd expect it to be fine to play with naming / values until stabilized?

[xiongmao86]

Appveyor build fatal: unable to access 'https://github.com/rust-lang/rustfmt.git/': Could not resolve host: github.com

May be failed because of network accessibility. How can I retry testing?

[scampi]

@RReverser ahah indeed ;oD that comment can be discarded then!

[xiongmao86]

@RReverser @scampi, then how to deal with rand's option if I switch to format_code_in_doc_comment?

And this pull request will separate wrap_comments with format_code_in_doc_comment that would cause code that imply format_code_in_doc_comment when wrap_comments is set to break, How to deal with that problem?

[scampi]

I believe mentioning the name change in the CHANGELOG should be good enough.

How to deal with that problem?

Given both options are unstable, nothing needs to be done. The behaviour of wrap_comments implying format_code_in_doc_comment was wrong to begin with.

[topecongiro]

LGTM, sorry for the late review.

[xiongmao86]

@RReverser @scampi @topecongiro, Thank you for helping and reviewing my commit. What should I do to get the pull request merge?

[RReverser]

Given the discussion above, I'd say rename the option back to format_code_in_doc_comments? (I see you reverted that change)

[xiongmao86]

Only rand build in Travis CI failed. I think this is probably good to go. @scampi, @topecongiro, What do you think?

[topecongiro]

@xiongmao86 Sorry for the late review. LGTM, thanks!