[Issue 23676] Compilation differences w/ braceless vs brace-full static if within switch statement

[Issue 23676] Static foreach hangs compilation for some time

Feb 10, 2023

RazvanN

Feb 11, 2023

Feb 11, 2023

Feb 14, 2023

Feb 14, 2023

Feb 15, 2023

Feb 15, 2023

Feb 22, 2023

https://issues.dlang.org/show_bug.cgi?id=23676 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |razvan.nitu1305@gmail.com Severity|minor |major --- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> --- This is a serious issue. Bumping severity to "major" --

https://issues.dlang.org/show_bug.cgi?id=23676 --- Comment #2 from Bradley Chatha <bradley@chatha.dev> --- Even more strangely: If you delete any line within the body of the case statement that is guarded by the fault `static if`, compilation succeeds. What a very strange edge case this is hitting. --

https://issues.dlang.org/show_bug.cgi?id=23676 --- Comment #3 from Bradley Chatha <bradley@chatha.dev> --- Marking the nested function as @safe prevents the error message; allows the compilation to succeed, however the compiler does still hang for a while before it finishes. --

February 10, 2023

[Issue 23676] Compilation differences w/ braceless vs brace-full static if within switch statement

Posted by RazvanN

Permalink

RazvanN

Permalink

https://issues.dlang.org/show_bug.cgi?id=23676

--- Comment #4 from RazvanN <razvan.nitu1305@gmail.com> ---
I manually reduced it to get rid of phobos and other unrelated features:

module lexer;

enum Type
{
    operatorSlash,
    operatorSlashEqual,
    operatorAnd,
    operatorAndEqual,
    operatorAndAnd,
    operatorQuestion,
    operatorDollar,
    operatorEqual,
    operatorEqualEqual,
    operatorStar,
    operatorStartEqual,
}

struct Lexer
{
    size_t _index;

    @safe:

    void nextOperator()
    {
        const couldLex = nextVaryingLengthToken();
    }

    // Complex reading //

    bool nextVaryingLengthToken()
    {
        alias TokenTypes = __traits(allMembers, Type);

        bool tryLexLongerOperators(alias TokenType)()
        {
            static foreach(type; TokenTypes)
            {
                _index++;
                if(tryLexLongerOperators!type)
                    return true;
                return true;
            }
        }

        return tryLexLongerOperators!noreturn;
    }
}

My hunch is that `static foreach` ends up generating too many recursive calls to  tryLexLongerOperators, but I don't know exactly what causes the hang.

--

https://issues.dlang.org/show_bug.cgi?id=23676 Basile-z <b2.temp@gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |b2.temp@gmx.com --- Comment #5 from Basile-z <b2.temp@gmx.com> --- The `static foreach` is not great (btw you can drop `static`) but the real culprit is the access to the struct member `_index` from the nested functions. That would be a problem of counter performance caused by the creation of closures. kcachegrind shows that the costy thing would be a cycle between `FuncDeclaration.needsClosure` and checkEscapingSiblings. --

https://issues.dlang.org/show_bug.cgi?id=23676 --- Comment #6 from Bradley Chatha <bradley@chatha.dev> --- Yeah, it does appear to be exponential. If you change the static foreach to include a loop index; and then guard its body under a `static if(i < 1)`, the slowdown appears to start at i < 8. So in other words, my code is bad and I should feel bad ;) (or more seriously it could be a combination of bad code and a bad pathway in the frontend). Curiously, `i < 1` allows the function to compile perfectly fine however `i < 2` makes you run into the `@safe function can't call @system function` error. Is that a seperate attribute inference bug or am I missing something, because you can easily add @safe onto the nested function to solve that problem. --

https://issues.dlang.org/show_bug.cgi?id=23676 --- Comment #7 from Bradley Chatha <bradley@chatha.dev> --- Though that also still doesn't explain the strange behaviour where using a bracefull body works fine, without causing the hang or the inference error, and using a braceless body causes the errors and the hang. --

Forums