[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Adela Vais
Subject: Re: [PATCH for Dlang support] d: make enum SymbolKind idiomatic D
Date: Thu, 1 Oct 2020 15:55:31 +0300

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

În joi, 1 oct. 2020 la 02:55, H. S. Teoh <> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]