<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On May 8, 2013, at 1:56 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, May 8, 2013 at 11:13 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br><blockquote type="cite"><br>On May 8, 2013, at 12:42 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br><br>On Wed, May 8, 2013 at 10:21 PM, Fariborz Jahanian <<a href="mailto:fjahanian@apple.com">fjahanian@apple.com</a>><br>wrote:<br>void Lexer::lexCommentText(Token &T) {<br>@@ -354,8 +355,17 @@ void Lexer::lexCommentText(Token &T) {<br> if (!Info) {<br> formTokenWithChars(T, TokenPtr, tok::unknown_command);<br> T.setUnknownCommandName(CommandName);<br>- Diag(T.getLocation(), diag::warn_unknown_comment_command_name);<br>- return;<br>+ if (Info = Traits.getTypoCorrectCommandInfo(CommandName)) {<br>+ StringRef CorrectedName = Info->Name;<br>+ SourceRange CommandRange(T.getLocation().getLocWithOffset(1),<br>+ T.getEndLocation());<br>+ Diag(T.getLocation(), diag::warn_correct_comment_command_name)<br>+ << CommandName << CorrectedName<br>+ << FixItHint::CreateReplacement(CommandRange, CorrectedName);<br><br><br>We recover by assuming that the user wanted this correction. What if<br>they did not?..<br><br><br>That's the way Fix-Its are meant to work: we suggest something when we have<br>a high level of confidence in it, and continue on as if the user had typed<br>what we suggested.<br></blockquote><br>Yes, but this is a warning, so the comment AST is produced anyway.<br>But comment parsing only produces warnings, there are no comment<br>errors (yet? :)<br></div></blockquote><div><br></div>Well, it'll be a less useful comment AST than if the correction was right.</div><div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite"><br>(But I can only imagine such situation only for<br>external users who use comment parsing for something non-Doxygen.)<br><br><br>This is what -fcomment-block-comments=<blah> is for, right?<br></blockquote><br>Yes, that option too. It registers block commands dynamically. But<br>we don't have an option to turn off built-in commands. There is also<br>a possibility that someone relies on all unknown commands being<br>treated as inline commands (but we now start typo-correcting someone's<br>command to a known block command). Anyway, all this can be fixed by<br>introducing two options in future (if someone needs it): an option to<br>turn off built-in commands, and an option to register inline commands<br>dynamically.<br></div></blockquote><div><br></div><div>We're balancing the needs of the community that uses Doxygen/HeaderDoc against the needs of the community that uses other documentation commands with the same style (but different command names). Personally, I feel like the first first community is much, much larger, and that the second community can turn off -Wdocumentation or use -fcomment-block-comments=<blah>. I fully agree that it makes sense to have -fcomment-inline-commands=<blah> and (less important) something to turn off the builtin commands, to help the second community get more out of Clang.</div><div><br></div></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug<div><br></div></body></html>