[cfe-dev] [PATCH] libclang interface for comments AST
Jean-Daniel Dupas
devlists at shadowlab.org
Fri Jul 20 10:21:11 PDT 2012
While you're working on comment parser, you may be interested by this bug:
http://llvm.org/bugs/show_bug.cgi?id=13411
This is a comment that make the comment parser crash (by assertion)
Le 20 juil. 2012 à 18:04, Douglas Gregor <dgregor at apple.com> a écrit :
>
> On Jul 19, 2012, at 2:18 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>
>> Hello,
>>
>> The attached patch adds libclang APIs to walk comments ASTs and an API
>> to convert a comment to an HTML fragment.
>
> This is awesome. Some minor comments below, but I think this is ready to go in.
>
>> I implemented error handling as returning bogus-but-safe values. I am
>> still concerned about this, because if the programmer misuses the API,
>> libclang will work around that silently. It could be a good idea to
>> add some opt-in debug output for libclang to scream in such cases.
>
> I think adding opt-in debug output for libclang is a wonderful (separable) idea.
>
>> For testing I implemented an equivalent of Comment::dump() with these
>> new APIs in c-index-test.
>
>
> Great!
>
> +void CommentASTToHTMLConverter::visitInlineCommandComment(
> + const InlineCommandComment *C) {
> + StringRef CommandName = C->getCommandName();
> + bool HasArg0 = C->getNumArgs() > 0 && !C->getArgText(0).empty();
> + StringRef Arg0;
> + if (HasArg0)
> + Arg0 = C->getArgText(0);
> +
> + if (CommandName == "b") {
> + if (!HasArg0)
> + return;
> + Result += "<b>";
> + Result += Arg0;
> + Result += "</b>";
> + return;
> + }
> + if (CommandName == "c" || CommandName == "p") {
> + if (!HasArg0)
> + return;
> + Result += "<tt>";
> + Result += Arg0;
> + Result += "</tt>";
> + return;
> + }
> + if (CommandName == "a" || CommandName == "e" || CommandName == "em") {
> + if (!HasArg0)
> + return;
> + Result += "<em>";
> + Result += Arg0;
> + Result += "</em>";
> + return;
> + }
>
> Here, we're classifying a subset of the Doxygen inline commands. Can you extract this operation out into a member function of InlineCommandComment, something like
>
> enum CXInlineCommandCommentKind {
> ICC_Unknown,
> ICC_Bold,
> ICC_Code,
> ICC_Emphasized
> };
>
> CXInlineCommandCommentKind getCommandCommentKind() const;
>
> or maybe tie it to the rendering of the text, e.g.,
>
> enum CXInlineCommandRenderKind {
> ICR_Normal,
> ICR_Bold,
> ICR_Code,
> ICR_Emphasized
> }
>
> CXInlineCommandRenderKind getRenderKind() const;
>
> so that all clients don't need to reinterpret the various Doxygen/HeaderDoc/etc. commands themselves (Unless they want to)? This information would be useful in the libclang API as well, since we expect many clients to use that.
>
> +/**
> + * \brief Convert a given full parsed comment to an HTML fragment.
> + *
> + * Specific details of HTML layout are subject to change. Don't try to parse
> + * this HTML back into an AST, use other APIs instead.
> + *
> + * \param Comment a \c CXComment_FullComment AST node.
> + *
> + * \returns string containing an HTML fragment.
> + */
> +CINDEX_LINKAGE CXString clang_FullComment_getAsHTML(CXComment Comment);
>
> Somewhere, we'll need to document the various classes that the emitted HTML uses (para-brief, para-returns, etc.). I suspect that there might be specific interest in those classes, since that's a (currently hidden, but very important) part of this interface.
>
> - Doug
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-- Jean-Daniel
More information about the cfe-dev
mailing list