Re: [PATCH for Dlang support] d: make enum SymbolKind idiomatic D

Adela Vais <[email protected]>
Newsgroups gmane.comp.parsers.bison.patches
Message-ID <CAPk8xGcPQuoFK9YFToLhMXy6s8ogGXdyHdbEOFuRqZHb5922rA@mail.gmail.com>
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.
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.