Jump to page: 1 2
Thread overview
please help me submit a bug!
Oct 08
workman
Oct 08
Basile B.
Oct 08
jfondren
Oct 08
Basile B.
Oct 08
jfondren
Oct 08
Basile.B
Oct 08
jfondren
Oct 09
workman
Oct 09
jfondren
Oct 09
jfondren
October 08

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

October 08

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

>

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

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.

October 08

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

>

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

>

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

Why do you think that there is a bug ?

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

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.

October 08

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

>

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

>

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

>

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

Why do you think that there is a bug ?

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

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.

You've replied to the wrong person.

October 08

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

>

You've replied to the wrong person.

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

> >

only one of those array literals involves the GC, so it would be pretty annoying for the compiler to not point it out.

October 08

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

>

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

>

You've replied to the wrong person.

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

> >

only one of those array literals involves the GC, so it would be pretty annoying for the compiler to not point it out.

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

October 08

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

>

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

>

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

>

You've replied to the wrong person.

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

> >

only one of those array literals involves the GC, so it would be pretty annoying for the compiler to not point it out.

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

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:

>

The problem is there is no easy way to find which line cause this error:
...
This function is huge, I hope compiler can print the the lines.

You then said

>

Why do you think that there is a bug ?

>

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

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.

October 09

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

>

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.

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.

October 09

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

>

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.

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;
}
October 09

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

>

I don't quite get it, but it looks like your enum T A is treated like a manifest constant,

That's because it is a manifest constant.

« First   ‹ Prev
1 2