Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
September 15, 2017 Internal error mixing templates and CTFE | ||||
---|---|---|---|---|
| ||||
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? |
September 15, 2017 Re: Internal error mixing templates and CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Bennett | 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
|
September 15, 2017 Re: Internal error mixing templates and CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrea Fontana | 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 |
September 15, 2017 Re: Internal error mixing templates and CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Bennett | 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 ?
|
September 17, 2017 Re: Internal error mixing templates and CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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. #0 0x00007f1d568658a8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x76e8a8) #1 0x00007f1d56863786 llvm::sys::RunSignalHandlers() (/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x76c786) #2 0x00007f1d568638e5 (/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x76c8e5) #3 0x00007f1d55ce2670 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11670) #4 0x00007f1d5509977f gsignal /build/glibc-mXZSwJ/glibc-2.24/signal/../sysdeps/unix/sysv/linux/raise.c:58:0 #5 0x00007f1d5509b37a abort /build/glibc-mXZSwJ/glibc-2.24/stdlib/abort.c:91:0 #6 0x00007f1d55091b47 __assert_fail_base /build/glibc-mXZSwJ/glibc-2.24/assert/assert.c:92:0 #7 0x00007f1d55091bf2 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbf2) #8 0x00005644df8d2310 (ldc2+0x3cb310) ... #25 0x00005644df909370 (ldc2+0x402370) #26 0x00007f1d550843f1 __libc_start_main /build/glibc-mXZSwJ/glibc-2.24/csu/../csu/libc-start.c:325:0 #27 0x00005644df6538ea (ldc2+0x14c8ea) Aborted (core dumped) ldc2 failed with exit code 134. |
Copyright © 1999-2021 by the D Language Foundation