[PATCH] D56913: decoupling Freestanding atomic<T> from libatomic.a

[Davide Italiano via llvm-commits]

On Mon, Mar 4, 2019 at 1:07 PM Louis Dionne <ldionne at apple.com> wrote:
>
>
>
> > On Mar 4, 2019, at 15:41, Jim Ingham <jingham at apple.com> wrote:
> >
> > lldb data formatters can be written using the lldb SB API's from either Python or from C++, and lldb can load both Python modules defining data formatters or shared libraries ditto.  One of the reasons we structured the data formatters the way we did was just so that library authors could support their own formatters.  Somehow, however, most library authors have been content for us to do the work for them ;-)  But if the libc++ maintainers wanted to take over maintaining the lldb data formatters for C++, there's nothing technical stopping them from doing so.  The SB API's are lldb's stable API's so data formatters written this way will work across a wide range of lldb versions.  We'd have to figure out packaging issues and the like, but if there's interest on your end this should be doable (*).
> >
> > BTW, another suggestion that has been floated is to come up with a debugger independent representation of the "important bits" of a class from which debuggers could synthesize a data formatter.  I'm not sure how easy it would be to come up with a rich enough description but up-sides would be that multiple debuggers could then support the rich view of the class, and the specification could live in the headers themselves, so distribution wouldn't be a problem.  This idea does seem like a bigger project...
> >
> > (*) Note, for reasons of expediency the current C++ data formatters are written using the lldb_private API's, which are not for external use.  That was in hindsight an unfortunate choice, it does mean the formatters would have to be rewritten from their current form to live separately from lldb.
>
> I think libc++ maintainers do not have sufficient bandwidth to migrate the data formatters (especially given the relatively low value added compared to other libc++ tasks). However, if someone else migrated the data formatters to libc++ and they were relatively easy to maintain, what I'm saying is that I'd be willing to make sure that we don't break those formatters when we make new commits. That is contingent on the formatters being tested as part of libc++, like I said before.
>
> Otherwise, in good faith, I'll try to remember running the data formatters when we change the ABI (even if that's not sufficient). But running the lldb test suite is too disruptive to the workflow to systematically run it pre-commit on each libc++ change. The status-quo is workable too -- we sometimes (but rarely) break the formatters, get notified by CI, and someone that knows the formatters well fixes the problem.
>
> Louis
>

Other people are working on this area of the codebase, and I touch it
relatively infrequently to have a strong opinion, but I'm under the
impression the status quo isn't really unreasonable.
Sometimes things break, and we fix them. The worst thing that can
happen is that the libcxx change is reverted for a short amount of
time until the issue is sorted out. No biggie.

--
Davide