[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
only.
În joi, 1 oct. 2020 la 02:55, H. S. Teoh <hsteoh@quickfur.ath.cx> 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.
>
>
- Re: [PATCH for Dlang support] d: make enum SymbolKind idiomatic D,
Adela Vais <=