Time for Phobos CTFE-ability unittests...right? RIGHT?

[Don]

Jonathan M Davis wrote:
> On 2011-07-12 17:16, Nick Sabalausky wrote:
>> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
>> news:mailman.1576.1310513383.14074.digitalmars-d at puremagic.com...
>>
>>> On 2011-07-12 16:17, Andrej Mitrovic wrote:
>>>> I don't understand what strip() could be doing to break CTFE anyway?
>>> Don has been making huge changes to CTFE. Stuff that didn't used to
>>> compile,
>>> now complie. Stuff which compiled but shouldn't have now doesn't compile.
>>> There's probably stuff which used to compile and should still compile
>>> which
>>> doesn't compile now too. But with all of those changes, I'm not sure that
>>> it's
>>> at all reasonable to expect CTFE-ability to be stable. It should be
>>> heading in
>>> that direction, but I'm not sure how stable Don considers it. Certainly,
>>> strip
>>> could be failing for a perfectly legitimate reason, or it could be a bug.
>>> I
>>> have no idea. But with all of the changes that have been being made to
>>> CTFE,
>>> I'm not at all surprised if stuff has quit working. There's probably more
>>> that
>>> works now that didn't before, but with all of the recent changes,
>>> breakage doesn't surprise me one bit.
>> I definitely expected that in 2.053, since that's the version that had the
>> CTFE overhaul. But it's not being re-overhauled in each version after
>> 2.053 - just bugfixes and added features. So at this point, I think it's
>> reasonable to expect that any CTFE changes that break Phobos code should be
>> fixed before release, even if only a temporary fix, in either the CTFE
>> engine or in the Phobos code that was broken.
> 
> Well, regardless of whether CTFE is still having a major overhaul, there's 
> still plenty of work being done on it. If you look at the changelog, you'll 
> see that there are a lot of CTFE-related changes, and I know that more CTFE 
> changes are in the works for 2.055 based on what Don has said. So, it doesn't 
> surprise me at all that issues with it are cropping up. And unless Don is 
> willing to say that we're going to guarantee the CTFEability of functions, 
> then there will be no guarantees of any functions remaining CTFEable, and 
> we're definitely not going to test that functions stay CTFEable.


2.053 fixed the fundamental wrong-code problem: array references didn't 
work AT ALL. But it only fixed local variables, not parameters.

2.054 fixed reference parameters. It also completely changed the 
treatment of slices.
After this, most of the wrong-code issues with CTFE were fixed. So that 
if it compiles in CTFE, it actually works.

2.054 also added support for pointers and heap-allocated structs.
This means that CTFE works in enough cases that a large chunk of Phobos 
should actually work now, and also means that most improvements to 
Phobos functions shouldn't cause CTFE to fail.

My plan is that 2.055 will clean up the smaller issues, which are of two 
types: (1) special cases that were overlooked (hopefully all of these 
will cause internal compiler errors rather than wrong-code); and (2) the 
compiler runtime helper functions.

This will leave the CTFE rules as:
(1) source code must be available;
(2) no access to global or static variables;
(3) no asm;
(4) no classes (and therefore, no interfaces, can't throw exceptions, etc);
(5) no closures.

(4) and (5) are only temporary limitations.
Note that for any function which is pure, we can expect that 
non-CTFEable regressions will happen only when external functions are 
called. Interestingly this is something which could be checked statically.
(CTFE can also use functions which aren't pure, but they're considerably 
more difficult to check, since they are CTFE-callable only for 
particular combinations of parameters).