On Tuesday, 1 August 2017 at 21:27:32 UTC, Stefan Koch wrote:
Sadly I temporarily broke the support for string-members in
structs.
Fixed now.
The issue was ABI related.
we used to store pointers to sliceDescriptors, but I changed that
to store the sliceDescriptors directly. Because otherwise slicing
of initializes of type string does not work.
I am happy I thought about this briefly two months ago, and to
have had the foresight to put in stubs for that, otherwise this
would have gotten much messier.
Another issue I want to deal with are void initalized struct
members.
In a few instances we can statically determine that they are
always initialized.
i.e. when there are no branches.
In most instances this is not the case though .... this requires
us to store a bitfield next to the this pointer of the struct
which indicated if a paricular member has been initialized or not.
Luckily we only need to do that for `= void` members. So I think
we can get away with 32bit.
I should mention that newCTFE does currently not support structs
with more then 96 member-variables anyway.
So far I have not come close to hitting that limit.
Talking about limits, this are the current limits I am aware of.
you can only use 16000 local variables per function.
you can only allocate around 265 Megabyte of heap-space per
evaluation.
Only functions with up to 64 parameters are supported.
you can only have up to 65535 instructions per function (roughly
16000 lines of code)
The call-stack can only be 2000 calls deep. (This is an artifical
limtation that the old interpreter imposed because it would die
and use insane amounts of memery wehen it went over that limit.
(With newCTFE you can safely bump that limit up to 5000 levels of
recursion .... but in order to pass all unittests we need to keep
the old limit))
You can only have about 12000 different struct types per
evaluation.
And only about 16000 assertions.
Similarly there may only be 7000 array-literals per function.
I don't see anyone reaching those limits soon.
Cheers,
Stefan
