diff options
author | David Blaikie <dblaikie@gmail.com> | 2014-08-29 16:53:14 +0000 |
---|---|---|
committer | David Blaikie <dblaikie@gmail.com> | 2014-08-29 16:53:14 +0000 |
commit | a97eaa1bc04636ad0d9e9b6b98f6c5cf6418dc7b (patch) | |
tree | d703dea6ca95a026d100ae5a02f94e5ba250685a /clang/tools/driver/cc1_main.cpp | |
parent | 2d3d6da44b2643e8adbd48669b4b8377d46d150d (diff) | |
download | bcm5719-llvm-a97eaa1bc04636ad0d9e9b6b98f6c5cf6418dc7b.tar.gz bcm5719-llvm-a97eaa1bc04636ad0d9e9b6b98f6c5cf6418dc7b.zip |
Provide a BuryPointer for unique_ptrs.
In theory, it'd be nice if we could move to a case where all buried
pointers were buried via unique_ptr to demonstrate that the program had
finished with the value (that we could really have cleanly deallocated
it) but instead chose to bury it.
I think the main reason that's not possible right now is the various
IntrusiveRefCntPtrs in the Frontend, sharing ownership for a variety of
compiler bits (see the various similar
"CompilerInstance::releaseAndLeak*" functions). I have yet to figure out
their correct ownership semantics - but perhaps, even if the
intrusiveness can be removed, the shared ownership may yet remain and
that would lead to a non-unique burying as is there today. (though we
could model that a little better - by passing in a shared_ptr, etc -
rather than needing the two step that's currently used in those other
releaseAndLeak* functions)
This might be a bit more robust if BuryPointer took the boolean:
BuryPointer(bool, unique_ptr<T>)
and the choice to bury was made internally - that way, even when
DisableFree was not set, the unique_ptr would still be null in the
caller and there'd be no chance of accidentally having a different
codepath where the value is used after burial in !DisableFree, but it
becomes null only in DisableFree, etc...
llvm-svn: 216742
Diffstat (limited to 'clang/tools/driver/cc1_main.cpp')
0 files changed, 0 insertions, 0 deletions