www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Internal error mixing templates and CTFE

reply David Bennett <davidbennett bravevision.com> writes:
Hi Guys,

I've been playing around with CTFE today to see how far I would 
push it but I'm having an issue appending to an array on a struct 
in CTFE from a template:

```
struct Content{
     string[] parts;
}

void add_part_to_content(Content content, string s)(){
     content.parts ~= "Part: "~s;
}

void main(){
     enum Content content = {};
     add_part_to_content!(content, "Header")();
}
```

This generates the following output:

& el:0x24052a0 cnt=0 cs=0 &  TY* 0x2403100
  el:0x2403100 cnt=0 cs=0 const  TYucent 0LL+0LL
Internal error: ddmd/backend/cgcs.c 352

FYI: I also get the same error with the template 
add_part_to_content(alias Content content, alias s) syntax.

So two questions:

Should what I'm doing be possible?

Is this an error in dmd, and should I open a bug report?
Sep 14 2017
next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Friday, 15 September 2017 at 05:58:47 UTC, David Bennett wrote:

 Is this an error in dmd, and should I open a bug report?


Internal error is always a bug, so it should be reported!

Andrea
Sep 15 2017
parent David Bennett <davidbennett bravevision.com> writes:
On Friday, 15 September 2017 at 07:12:36 UTC, Andrea Fontana 
wrote:

 Internal error is always a bug, so it should be reported!


I have opened a issue: 
https://issues.dlang.org/show_bug.cgi?id=17828
Sep 15 2017
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 15 September 2017 at 05:58:47 UTC, David Bennett wrote:

 Hi Guys,

 I've been playing around with CTFE today to see how far I would 
 push it but I'm having an issue appending to an array on a 
 struct in CTFE from a template:

 [...]


are you using ucent ?
Sep 15 2017
parent David Bennett <davidbennett bravevision.com> writes:
On Friday, 15 September 2017 at 15:48:10 UTC, Stefan Koch wrote:

 are you using ucent ?


Not that I know of, the code above is the full code (not sure 
what's used internally for string literals).

I was using dmd 2.076 from the apt repo but the error also 
happens in LDC 1.3[1].

Is there an easy way for me to test newCTFE?

The reduced version to get the same error is:

```
struct Content{string[] parts;}

void main(){
     enum Content content = {};
     content.parts ~= "";
}
```

Strange (for a CTFE noob like me anyway) thing is the following 
code produces no error or warning. (obviously it doesn't do what 
it looks like it does)

```
struct Content{
     string[] parts;
     void add(string s)(){
         parts ~= "Part: "~s;
     }
}

void main(){
     enum Content content = {};
     content.add!("Header")();
}
```

I would have thought both the code in the OP and the above two 
codes should produce a warning pointing out that using a compile 
time value like that has no useful effect. As this would be 
useful information for noobs like me...

Actually now that I think about it there could be a "valid" use.. 
ie if the add function set global state... does this even work... 
(checks) ... yes it does... so I guess a warning cant really 
happen then.


[1] Here is the LDC backtrace:

ldc2: /build/ldc-6CClyQ/ldc-1.3.0/gen/dvalue.cpp:43: llvm::Value* 
DtoLVal(DValue*): Assertion `lval' failed.

llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x76e8a8)

(/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x76c786)

(/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x76c8e5)

(/lib/x86_64-linux-gnu/libpthread.so.0+0x11670)

/build/glibc-mXZSwJ/glibc-2.24/signal/../sysdeps/unix/sysv/linux/raise.c:58:0

/build/glibc-mXZSwJ/glibc-2.24/stdlib/abort.c:91:0

/build/glibc-mXZSwJ/glibc-2.24/assert/assert.c:92:0


...


/build/glibc-mXZSwJ/glibc-2.24/csu/../csu/libc-start.c:325:0

Aborted (core dumped)
ldc2 failed with exit code 134.
Sep 17 2017