================
@@ -2032,6 +2032,7 @@ class SourceManagerForFile {
// as they are created in `createSourceManagerForFile` so that they can be
// deleted in the reverse order as they are created.
std::unique_ptr<FileManager> FileMgr;
+ std::unique_ptr<DiagnosticOptions> DiagOpts;
----------------
ojhunt wrote:
@jansvoboda11 the problem is that now an author does not know if a given
DiagnosticOption is a unique_ptr or a shared_ptr. A given DiagnosticOption* may
or may not be protectable, etc depending on the context and origin of the
object.
Philosophically I prefer intrusive refcounts over shared_ptr because to me they
make the lifetime much clearer as the lifetime rules are embedded in the type,
but I don't think that's an issue in this PR.
My understanding is that the goal of this PR is to say "For API purposes, a
given DiagnosticOption reference is only live as long as the API object that
vends it. As an implementation detail there are some cases where it can outlast
the vending object, but that's not generally part of the user visible API."
That's a perfectly reasonable change, but my concern is that by mixing and
matching shared and unique_ptr an author loses the ability to reason about what
a given object's lifetime is. It seems like the reason for shared_ptr is to
deal with some slightly gross bits of the API, and I wonder if it's possible to
fix those APIs so we can just use unique_ptr everywhere?
https://github.com/llvm/llvm-project/pull/139584
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
