[Dlang-internal] Detect CTFE in AssignExp:semantic

[Martin Nowak via Dlang-internal]

On Wednesday, 11 January 2017 at 17:10:15 UTC, Andrei 
Alexandrescu wrote:
> On 1/11/17 3:16 PM, Martin Nowak wrote:
>> On Wednesday, 11 January 2017 at 09:05:44 UTC, Lucia Cojocaru 
>> wrote:
>>> The dmd code (e2ir.d and expression.d are of interest):
>>> https://github.com/somzzz/dmd/commit/8bccc49ba661567c523545650aad30c01fd25090
>>>
>>
>> Calls for the old dmd<->C-API are very different from template 
>> functions
>> calls, e.g. take a look at how _xOpEquals is called.
>> https://github.com/dlang/dmd/blob/538a895157acdbbfc5869791f9504f7e86b4fdd0/src/clone.d#L496
>
> Cool. That looks different from 
> https://github.com/somzzz/dmd/commit/8bccc49ba661567c523545650aad30c01fd25090, is the latter appropriate as well? Or perhaps that's why the error with reading the variable during compilation?
>
>>> The druntime template:
>>
>> https://github.com/somzzz/druntime/commit/6cf9cbc6650697d8a038be7076e588601aefe954
>>
>>
>>> The example which doesn't compile is a standalone code 
>>> snippet which
>>> reproduces the error encountered. I started from the code in 
>>> druntime
>>> and simplified it to that point. As of your suggestions, I 
>>> will
>>> simplify it further and come back with another example.
>>
>> You cannot distinguish between ctfe/non-ctfe during semantic. 
>> Only the
>> backend/glue layer differs between CTFE (interpret.d) and 
>> IR/codegen
>> (e2ir).
>> If you want to convert a C-API intrinsic to a template 
>> function call,
>> you'd usually deal with __ctfe in druntime not in the compiler.
>> DMD will always call the druntime function and if that happens 
>> during
>> CTFE, it'll get interpreted.
>
> OK, but the problem here is it indicates a problem at the call 
> site of _d_arraycopyT, not inside the implementation. Is there 
> an issue with the way the code is generated?

Don't really understand your question. What are the 2 problems 
you refer to?

The difference is fairly simple but huge:

- C intrinsics
   - AssignExp.semantic
     - e2ir => call RTLSYM_SYM
     - interpret => special handling

- D lowering
   - AssignExp.semantic lowered to CallExp of object._arrayCopy
     - normal function call and no special CTFE handling

> Also, as an aside: the _d_arraycopyT should probably go like 
> this:
>
> D _d_arraycopyT(S, D)(S from, D to) { ... }
> You don't need size because it's from[0].sizeof. Correct?

Just convert the assignment to a function call, the backend deals 
with optimizations et.al. Also this seems to be used not only for 
static arrays.

NB:
   - leave aways the _d prefix it's only needed to namespace 
extern(C) functions with flat mangling
   - prolly should be _arrayCopy(T)(in T[] from, T[] to) as 
AssignExp.semantic already takes care of conversions