I can not finish the register some how.

The problem is there is no easy way to find which line cause this error:

Error: array literal in @nogc function app.test.updateBy!("updated_at", "counter").updateBy may cause a GC allocation

This function is huge, I hope compiler can print the the lines.

I test on LDC2 1.28.0-beta1

On Friday, 8 October 2021 at 14:01:40 UTC, workman wrote:

Why do you think that there is a bug ?

D array literals are dynamic arrays, so the GC is used.

If the function in which resides the call to updateBy is @nogc then it is probable that updateBy becomes @nogc by attribute inference, except that it cant because of the array literal.

Possible workaround: if the array literal contains simple values that are known at compile time try to declare it static immutable.

On Friday, 8 October 2021 at 14:42:08 UTC, Basile B. wrote:

T somef(T, size_t U)(T[U] array) { return array[0]; }
int otherf(int[] array) { return array[0]; }

@nogc unittest {
    import std.array : staticArray;

    int[5] a1 = [1, 2, 3, 4, 5];
    auto a2 = staticArray!([1, 2, 3]);
    auto a3 = somef([0, 5, 10]);
    auto a4 = [1, 2, 3];
    enum a5 = otherf([9, 8, 7]);
}

only one of those array literals involves the GC, so it would be pretty annoying for the compiler to not point it out. However, in this example, the compiler does say which line the error's on. That's the number in parentheses right before "Error:"

example.d(10): Error: array literal in `@nogc` function `example.__unittest_L4_C7` may cause a GC allocation

To submit an issue I'd need an example of where it doesn't include the line number.

On Friday, 8 October 2021 at 15:15:52 UTC, jfondren wrote:

T somef(T, size_t U)(T[U] array) { return array[0]; }
int otherf(int[] array) { return array[0]; }

@nogc unittest {
    import std.array : staticArray;

    int[5] a1 = [1, 2, 3, 4, 5];
    auto a2 = staticArray!([1, 2, 3]);
    auto a3 = somef([0, 5, 10]);
    auto a4 = [1, 2, 3];
    enum a5 = otherf([9, 8, 7]);
}

example.d(10): Error: array literal in `@nogc` function `example.__unittest_L4_C7` may cause a GC allocation

You've replied to the wrong person.

On Friday, 8 October 2021 at 15:51:53 UTC, Basile B. wrote:

I haven't. These two lines are a reply to you:

On Friday, 8 October 2021 at 15:53:40 UTC, jfondren wrote:

Who said that the compiler should not point the problem out ?

On Friday, 8 October 2021 at 18:30:28 UTC, Basile.B wrote:

Nobody said that the compiler should not point the problem out, but workman, in the beginning of this thread, said that the compiler did not point the problem out:

You then said

Which I interpreted to mean that you reckon the problem should be trivial to find even with the compiler not pointing it out, because the problem will be a D array literal which all use the GC.

In reply to that, I showed you some code with five D array literals, only one of which uses the GC. If workman's huge function has many D array literals and he's already tried going through them to find the problem and hasn't yet, he might have a haystack like this to sort through.

One of these is probably the case:

1. workman overlooked the line number in the error output--there is no bug

2. workman did not overlook the line number but thinks it not helpful enough. By "I hope compiler can print the lines" he means that he wants more verbose output that points to the array literal in context and explains why it uses the GC.

3. there is a bug and the compiler sometimes doesn't print the error number.

There are a lot of possibilities but the thread still isn't a mystery novel.

On Friday, 8 October 2021 at 19:21:45 UTC, jfondren wrote:

Thanks for the list and tips.

It take me a lot time to location the bugs:

struct T {
        int     b;
        ubyte[] a;
}

enum T A = T(3, [1]);


extern(C) int  main(int argc, char** argv) @nogc nothrow {
        if(argc > 1 &&  A.b ) {
                return 0;
        }
        return 0;
}

test.d(7): Error: array literal in `@nogc` function `test.main` may cause a GC allocation

I am not able to find it because it not throw by a array literal, but by call a enum struct int filed(this struct also include a dynamic array).

In this case I dont get the line number, and this A.b should be compile time const.

On Saturday, 9 October 2021 at 05:34:28 UTC, workman wrote:

struct T {
        int     b;
        ubyte[] a;
}

enum T A = T(3, [1]);


extern(C) int  main(int argc, char** argv) @nogc nothrow {
        if(argc > 1 &&  A.b ) {
                return 0;
        }
        return 0;
}

test.d(7): Error: array literal in `@nogc` function `test.main` may cause a GC allocation

this works:

struct T {
    int b;
    ubyte[] a;
}

// toplevel const implies static
const T A = T(3, [1]);

extern (C) int main(int argc, char** argv) @nogc nothrow {
    if (argc > 1 && A.b) {
        return 0;
    }
    return 0;
}

as does this:

extern (C) int main(int argc, char** argv) @nogc nothrow {
    enum Ab = A.b;
    if (argc > 1 && Ab) {
        return 0;
    }
    return 0;
}

I don't quite get it, but it looks like your enum T A is treated like a manifest constant, so it's like you wrote this with a runtime construction of the struct and with a GC-allocated [1]:

extern (C) int main(int argc, char** argv) @nogc nothrow {
    if (argc > 1 && T(3, [1]).b) {
        return 0;
    }
    return 0;
}

On Saturday, 9 October 2021 at 05:46:50 UTC, jfondren wrote:

That's because it is a manifest constant.