Thank you for the tip! I'll see how I can test with the -unittest flag for non-Bison related parts inside the repo (like this issue, with GC). I'll have to think about how I want to that because I wouldn't want the unit tests to end up in the user's code, I want them for internal testing only.
În joi, 1 oct. 2020 la 02:55, H. S. Teoh <[email protected]> a scris: > On Thu, Oct 01, 2020 at 02:40:25AM +0300, Adela Vais wrote: > > Hello, > > > > I realized that I was still triggering the GC within the toString > > function. Fixed now. > [...] > > Here's an idiom you might find useful for catching things like hidden > unwanted GC allocations: > > struct S { > string x; > void toString(W)(W sink) { > sink(x ~ "a"); > } > > @nogc unittest { > S s; > static void sink(const(char)[]) {} > s.toString(&sink); > } > } > > The @nogc on the unittest ensures that it will not compile if toString > has any hidden GC allocations. But it will not stop the user from > calling toString with an allocating sink, as it would if we had put > @nogc on toString itself. By not putting @nogc on toString, we allow > the user to choose whether or not they want to use an allocating sink or > not; the @nogc on the unittest ensures that toString itself will not > introduce GC dependency, thus making toString compatible with both. > > (Note: for this to work, the code must be compiled with -unittest. I > highly, highly recommend building with -unittest as part of the test > suite.) > > > T > > -- > Give me some fresh salted fish, please. > >
