[cfe-dev] [RFC] Removing libclang APIs to traverse the comment AST

Dmitri Gribenko gribozavr at gmail.com
Wed Nov 13 18:33:17 PST 2013


On Wed, Nov 13, 2013 at 6:21 PM, Sean Silva <silvas at purdue.edu> wrote:
>
> On Wed, Nov 13, 2013 at 9:05 PM, Dmitri Gribenko <gribozavr at gmail.com>
> wrote:
>>
>> On Wed, Nov 13, 2013 at 6:01 PM, Sean Silva <silvas at purdue.edu> wrote:
>> >
>> > On Wed, Nov 13, 2013 at 8:25 PM, Dmitri Gribenko <gribozavr at gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Nov 13, 2013 at 5:22 PM, Sean Silva <silvas at purdue.edu> wrote:
>> >> >
>> >> > On Wed, Nov 13, 2013 at 8:08 PM, Dmitri Gribenko
>> >> > <gribozavr at gmail.com>
>> >> > wrote:
>> >> >> Or we could only return the first paragraph.  Faking a paragraph
>> >> >> requires creating AST nodes, which requires memory allocation on the
>> >> >> ASTContext, which is permanent.
>> >> >
>> >> > Why not create it on demand in "freeable" storage?
>> >>
>> >> There is no API to free a CXComment node, because it is supposed to
>> >> represent an real AST node, which is allocated on ASTContext.
>> >
>> >
>> > Can't you allocate it on the CXTranslationUnit (or whatever the relevant
>> > nearby "context" object is that is explicitly created/destroyed)?
>>
>> There is no difference, because the lifetime of these contexts is the
>> same.
>
> Wait then what's the big deal with just allocating them permanently? It's
> not like these comments are going to be gigabytes in size.

Not gigabytes, but possibly very large.  For example, on OS X, the
text of fully preprocessed Cocoa.h with comments takes over 90 Mb.

Anyway, I see that a stable API promise from libclang is not to be
taken lightly, so it might be the case that we will need to keep these
APIs.  But this case clearly shows that exposing such low-level
details is not sustainable, and leads to unfortunate workarounds.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/



More information about the cfe-dev mailing list