Thread overview
Re: bug with CTFE std.array.array ?
Jul 11, 2013
Jonathan M Davis
Jul 11, 2013
Timothee Cour
Jul 11, 2013
Kenji Hara
July 11, 2013
On Wednesday, July 10, 2013 18:06:00 Timothee Cour wrote:
> import std.array;
> 
> void main(){
> //enum a1=[1].array;//NG: Error: gc_malloc cannot be interpreted at
> compile time
> enum a2=" ".array;//OK
> 
> import std.string;
> //enum a3=" ".splitLines.array;//NG
> enum a4="".splitLines.array;//OK
> enum a5=" ".split.array;//OK
> //enum a6=" a ".split.array;//NG
> import std.algorithm:filter;
> enum a7=" a ".split.filter!(a=>true).array;
> auto a8=" a ".split.array;
> assert(a8==a7);
> enum a9=[1].filter!(a=>true).array;//OK
> }
> 
> 
> I don't understand why the NG above fail (with Error: gc_malloc cannot be interpreted at compile time)
> 
> furthermore, it seems we can bypass the CT error with interleaving
> filter!(a=>true) (see above), which is even weirder.

I expect that it's a matter of code path. Some code paths don't hit anything which is illegal in CTFE, but apparently at least one of them uses gc_malloc, which is apparently illegal in CTFE, so when it gets hit, CTFE fails. Presumably, to fix it, either it needs to be changed to not use gc_malloc or changed so that it doesn't use gc_malloc with CTFE (by using __ctfe). I'd have to actually dig through the code to verify exactly what it's doing though.

- Jonathan M Davis
July 11, 2013
On Wed, Jul 10, 2013 at 6:11 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Wednesday, July 10, 2013 18:06:00 Timothee Cour wrote:
> > import std.array;
> >
> > void main(){
> > //enum a1=[1].array;//NG: Error: gc_malloc cannot be interpreted at
> > compile time
> > enum a2=" ".array;//OK
> >
> > import std.string;
> > //enum a3=" ".splitLines.array;//NG
> > enum a4="".splitLines.array;//OK
> > enum a5=" ".split.array;//OK
> > //enum a6=" a ".split.array;//NG
> > import std.algorithm:filter;
> > enum a7=" a ".split.filter!(a=>true).array;
> > auto a8=" a ".split.array;
> > assert(a8==a7);
> > enum a9=[1].filter!(a=>true).array;//OK
> > }
> >
> >
> > I don't understand why the NG above fail (with Error: gc_malloc cannot be interpreted at compile time)
> >
> > furthermore, it seems we can bypass the CT error with interleaving
> > filter!(a=>true) (see above), which is even weirder.
>
> I expect that it's a matter of code path. Some code paths don't hit
> anything
> which is illegal in CTFE, but apparently at least one of them uses
> gc_malloc,
> which is apparently illegal in CTFE, so when it gets hit, CTFE fails.
> Presumably, to fix it, either it needs to be changed to not use gc_malloc
> or
> changed so that it doesn't use gc_malloc with CTFE (by using __ctfe). I'd
> have
> to actually dig through the code to verify exactly what it's doing though.
>
> - Jonathan M Davis
>

in the meantime, one can do:

auto ctfe_array(T)(T a){
import std.algorithm:filter;
import std.array:array;
return a.filter!(a=>true).array;
}
unittest{
  //enum a1=[1].array;//NG
  enum a2=[1]. ctfe_array;//OK
}

but why not change std.array.array to this:

auto array(T)(T a){
if(__ctfe){
import std.algorithm:filter;
return a.filter!(a=>true). arrayImpl;
}
else{
return arrayImpl(a);
}
}

auto arrayImpl(T)(T a){...}//move current implementation here

That would at least temporarily solve the problem, until a better fix is found.


July 11, 2013
This issue is already fixed in git head.

Kenji Hara

2013/7/11 Timothee Cour <thelastmammoth@gmail.com>

> import std.array;
>
> void main(){
>   //enum a1=[1].array;//NG: Error: gc_malloc cannot be interpreted at
> compile time
>   enum a2=" ".array;//OK
>
>   import std.string;
>   //enum a3=" ".splitLines.array;//NG
>   enum a4="".splitLines.array;//OK
>   enum a5=" ".split.array;//OK
>   //enum a6=" a ".split.array;//NG
>   import std.algorithm:filter;
>   enum a7=" a ".split.filter!(a=>true).array;
>   auto a8=" a ".split.array;
>   assert(a8==a7);
>   enum a9=[1].filter!(a=>true).array;//OK
> }
>
>
> I don't understand why the NG above fail (with Error: gc_malloc cannot be interpreted at compile time)
>
> furthermore, it seems we can bypass the CT error with interleaving
> filter!(a=>true) (see above), which is even weirder.
>