Re: [outcome] Inline GDB pretty printing support

From: Braden Ganetsky (braden.ganetsky_at_[hidden])
Date: 2024-08-08 18:09:03

When I wrote the Natvis visualizers for Unordered, I was looking into
automated unit testing and couldn't figure out a way to get that to work.
In the end I settled on a test file with a specific location to break, then
check the debugger window manually. If there's anything out there in terms
of automated unit testing for Natvis, I want to know.

Similarly, I'm working on pretty-printers for Unordered at the moment, and
I would love some automated testing there as well. (Incidentally, I may
need to reach out privately for some help on the inline asm stuff.)

Mainly, I'm sending this message to also express interest in a visualizer
test framework. I think visualizers are a very important part of library
authorship, and it would encourage more people to write visualizers if the
testing was more rigorous and easier to hook into.

On Thu, Aug 8, 2024, 12:36 PM Niall Douglas via Boost <boost_at_[hidden]>
wrote:

> On 08/08/2024 17:56, Vinnie Falco via Boost wrote:
> > On Wed, Aug 7, 2024 at 4:04 PM Jeff Trull via Boost <
> boost_at_[hidden]>
> > wrote:
> >
> >> Creating a formal framework for them to be included with Boost itself
> would
> >>   be pretty cool.
> >
> >
> > We could add a section "Debugger Visualizers" to the Contributor's Guide.
> > At first it can just list some resources, and over time we can add best
> > practices and examples for how authors and maintainers may add support to
> > their libraries.
>
> I would much rather that the maintainer of the library inlines the
> visualisers for their library, and then maintains them over time as
> their library changes.
>
> To make this work well, what we really need and don't have is a
> visualiser testing framework i.e. unit tests will fail if your
> visualiser stops matching your C++.
>
> I fell foul of this exact problem:
>
> https://github.com/ned14/outcome/issues/301
>
> I suspect that another copy of the visualiser overrode the inline one,
> and so I didn't see this failure until it was too late (master is now
> locked).
>
> What would be super great (hint: C++ Alliance funded) is if Boost had
> convenient tooling which in both b2 and cmake invoked the gdb/MSVC
> debugger during unit tests and checked that a corpus of library use
> snippets do produce the correct visualisations in the debugger.
>
> It's a chunky enough bit of work, highly unlikely to be done in
> volunteer time as it'll be tedious and boring and annoying.
>
> Niall
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>