#485 Negative integer literal breaks initializer list formatting

[w-peuker]

Astyle 3.1 breaks the formatting of constructor (if not inlined) after encountering a negative integer literal, if this is already indented. To illustrate this,

class TestClass
{
    int m_a;
    int m_b;
    int m_c;
    int m_d;
    TestClass();
};

TestClass::TestClass():
    m_a(
        1
    ),
    m_b(
        -1
    ),
    m_c(
        -1
    ),
    m_d(
        1
    )
{
}

is getting changed into:

class TestClass
{
    int m_a;
    int m_b;
    int m_c;
    int m_d;
    TestClass();
};

TestClass::TestClass():
    m_a(
        1
    ),
    m_b(
        -1
        ),
        m_c(
    -1
        ),
        m_d(
        1
        )
{
}

In my actual case, it's a long initializer list of members that needed more than one constructor argument so I listed the sub constructor arguments vertically (not shown here). The formatting is correct until the first negative integer literal: If I replace this literal by an enum or preprocessor define, the formatting will be correct for the entire initializer list. (The problem doesn't seem to affect inline construtors.)

I use the commad line astyle test.cpp which I reduced to the minimum preserving the issue, the input file is attached.

[w-peuker]

I have to state that the issue applies to every signed expression, regardless of being an integer or a literal at all, even a parenthesized expression prefixed by sign ([+-]) causes malformatting. As I tested out now, a sign as the first nonspace characted in an initializer list confuses astyle 3.1.

I hope the bug ticket title can be changed to that.

I have the strong feeeling that this was introduced by r597 in AStyle/src/ASBeautifier.cpp at @@ -3566,8 +3566,10 @@ which is currently around line 3634 (r638, trunk)

I didn't really bisect for it. But when I saw these two lines

                 && ASBase::peekNextChar(line, i) != '-'
                 && ASBase::peekNextChar(line, i) != '+'

I changed my test to

Test485::Test485():
    a(
        -,1
    ),
    b(
        1
    )
{
}

to see it in work, after checking some valid combinations (regex $\s*[+-]\s*[\w\d(]).

I hope this will help you fixing it. Since I don't understand the whole picture, I resisted from constructing a patch.

[André Simon]

Fixed in 3.2.1