[cfe-commits] r60900 - in /cfe/trunk: include/clang/Parse/Ownership.h

[Sebastian Redl]

steve naroff wrote:
>
> On Dec 14, 2008, at 10:59 AM, Sebastian Redl wrote:
>
>> Now consider an IDE that integrates the Clang libraries for online 
>> syntax checking, auto-completion information, and similar things. 
>> Given that it works on code being edited, there will be lots of 
>> errors, and every single compilation with errors will leak.
>>
>
> Are you saying that the only way to plug the leaks is to use smart 
> pointers *everywhere*?
No. You could alternatively do a close audit of every commit do make 
sure every single control path carefully deletes all objects of which 
the current function retains ownership.
The current state of the parser and sema tells me that this wasn't 
happening. So, let the compiler do the audit instead, and let 
programmers focus on the difficult cases, i.e. where raw pointers are used.
>
>> The moment the IDE implementor realizes this, he will think very hard 
>> about not using Clang.
>>
>
>
> As you are well aware, clang is an Open Source project that is under 
> active development. Memory leaks would certainly need to be addressed 
> before IDE integration is practical. In general, clang's architecture 
> has been driven by it's clients. If you are integrating clang within 
> an IDE, then I am confident your work will indeed solve problems faced 
> by IDE developers.
I'm not doing this. But it was a scenario Chris mentioned when I 
initially posted about the leaks.
>
>>
>>> In general, the Parser doesn't do much dynamic memory allocation 
>>> (yet you've had to make *many* changes to the Parser/Action API's).
>> This is not really true. While the parser doesn't do much dynamic 
>> memory allocation by itself, it handles very many heap-allocated 
>> objects from Sema.
>
> It *is* true. Sema does the allocation, not the Parser. Since Sema 
> does the allocation, I don't know why the Parser interface needs to 
> change.
It isn't about who does allocations, it's about who has ownership. If 
the Sema does an allocation and passes the ownership of the object to 
the parser, then the parser is fully responsible for the object.
I personally believe that the ability to encode ownership in types is 
sufficient reason to do it. Since C++ has a very expressive, statically 
checked type system, it seems a waste not to put as much information as 
possible in there. Most people I know who like C++ like it because of 
the strong and expressive typing, as opposed to the uncertainty you 
often have in dynamic languages.
If you encode ownership in types, the interface between parser and sema 
has to change.

Sebastian