(In reply to comment #0)
> Recently found this one in my GSOC project. As this involves compilation of
> regex at CTFE, I'm not yet able to produce small test case.
> 
> dmd spits this:
> ..\..\fred.d(2020): Error: CTFE internal error: illegal stack value stack
> 
> Assertion failure: 'isStackValueValid(newval)' on line 5452 in file
> 'interpret.c'
> 
> abnormal program termination
> 
> But anyway, what kind of situation is supposed to trigger that assert?

Any kind of CTFE assignment involving a non-reference type, that wasn't tested.
The few lines involving the variable 'stack' around line 2020 will be the only ones involved in the bug.

Created attachment 1018 [details]
test case, stripped down parser

I've managed to get a resonably sized test case.
Apparently it has soemthing to do with -inline:

dmd fred.d  // Ok
dmd -inline fred.d //same error as before

I haven't made this point clear enough I think: the full source also fails only with -inline.

Partially reduced test case. The UNUSED static function seems to be necessary.

struct Stack(U) {
    struct Proxy { 
        int[] data;
        void shrink(){   data = data[0..0]; }
    }
    Proxy stack;
    void pop() {
        stack.shrink();
    }
}

int bug6510() {
    static void UNUSED() {
        Stack!(int) junk;
        junk.pop();
    }
    Stack!(int) opstk;
    opstk.pop();
    return 3;
}

 static assert(bug6510());

Reduced slightly further. If you uncomment the alias, everything works. So this is a bug which only happens when the semantic pass, and the inlining, is run on Stack!int *during* CTFE.
The stack.shrink() call gets translated into:
ref Proxy ths = this.stack;
which CTFE chokes on. Note that this is a local reference variable, which isn't legal D (it can only happen in compiler-generated code).

When the alias is present, the inline scan of bug6510() doesn't happen until after CTFE has finished. But interestingly an inline scan of UNUSED() still happens during CTFE.

---

struct Stack(U) {
    struct Proxy { 
        void shrink() {}
    }
    Proxy stack;
    void pop() {
        stack.shrink();
    }
}

alias Stack!int Stuck;

int bug6510() {
    static void UNUSED() {
        Stack!(int) junk;
        junk.pop();
    }
    Stack!(int) opstk;
    opstk.pop();
    return 3;
}

static assert(bug6510());

Thanks for getting a workaround so fast, it's just awesome.
I confirm that the full source works after I added aliases to Stack!(x).

(In reply to comment #7)
> Thanks for getting a workaround so fast, it's just awesome.
> I confirm that the full source works after I added aliases to Stack!(x).

I think the workaround is just luck, though, and may be quite fragile.
There seems to be something wrong at a fairly deep level, which doesn't involve CTFE. If you remove the static assert (so that CTFE isn't involved at all), then the presence or absence of the alias affects what gets inlined.

If there is no alias, semantic3() gets done on Stack before any inlining happens.
shrink and pop both get inlined in UNUSED, then pop gets inlined in bug6510.
It seems to be the inlining of 'shrink' inside 'pop' from 'unused' which is the problem.

But, if the alias is present, no inlining happens in UNUSED, but shrink and pop both get inlined in bug6510.
It seems wrong to me that the alias inhibits inlining. There also seems to be something wrong with the inlining itself.

Further reduced, showing that templates are not required. Seems to require an inlined member function call to a member of a nested struct, called from a nested function. No alias trick works in this case.

struct Stack6510 {
    struct Proxy { 
        void shrink() {}
    }
    Proxy stack;    
    void pop() {
        stack.shrink();        
    }
}

int bug6510() {
    static int used() {
        Stack6510 junk;
        junk.pop();
        return 3;
    }
    return used();
}

void main() {
    static assert(bug6510()==3);
}

https://github.com/D-Programming-Language/dmd/commit/563a291a5c7757fca87685909afa37100e3b44f6