• workman (8/8) Oct 08 2021 I can not finish the register some how.
• Basile B. (10/18) Oct 08 2021 Why do you think that there is a bug ?
• jfondren (23/39) Oct 08 2021 ```d
• Basile B. (2/46) Oct 08 2021 You've replied to the wrong person.
• jfondren (2/5) Oct 08 2021
• Basile.B (2/7) Oct 08 2021 Who said that the compiler should not point the problem out ?
• jfondren (25/41) Oct 08 2021 Nobody said that the compiler *should* not point the problem out,
• workman (25/36) Oct 08 2021 Thanks for the list and tips.
• jfondren (38/61) Oct 08 2021 this works:
• Mike Parker (2/4) Oct 08 2021 That's because it *is* a manifest constant.
• jfondren (11/17) Oct 08 2021 https://dlang.org/spec/enum.html#manifest_constants

workman <workman gmail.com> writes:

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

Basile B. <b2.temp gmx.com> writes:

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`.

jfondren <julian.fondren gmail.com> writes:

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.

```d
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.

Basile B. <b2.temp gmx.com> writes:

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.

 ```d
 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.

jfondren <julian.fondren gmail.com> writes:

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.

Basile.B <b2.temp gmx.com> writes:

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 ?

jfondren <julian.fondren gmail.com> writes:

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.

workman <workman gmail.com> writes:

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:

```d
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;
}

```

```sh
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.

jfondren <julian.fondren gmail.com> writes:

On Saturday, 9 October 2021 at 05:34:28 UTC, workman wrote:
 It take me a lot time to location the bugs:

 ```d
 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;
 }

 ```

 ```sh
 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:

```d
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:

```d
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]`:

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

Mike Parker <aldacron gmail.com> writes:

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.

jfondren <julian.fondren gmail.com> writes:

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

https://dlang.org/spec/enum.html#manifest_constants

Note, the spec doesn't have the "copy and paste" language that 
people use to describe the pitfall with enum array literals. I 
think that behavior's purely implied by enums not referring to 
runtime locations:

Manifest constants are not lvalues, meaning their address cannot 
be taken. They exist only in the memory of the compiler.
Better, the manifest constant has no runtime location in the 
executable.

With the `const T A` version, `A.b` refers to a specific location 
in the process's memory. With the `enum T A` version, `A.b` since 
it's in a runtime context must build the struct on the spot, and 
since the struct is mutable (unlike a string's bytes) it must be 
freshly constructed on each occurrence.