Generic.Formatting.MultipleStatementAlignment error with const DEFAULT

[caseyjhol]

Describe the bug
I'm getting an error when attempting to align the assignment tokens when defining constants, if one of the constants is named DEFAULT. It's trying to align DEFAULT with the array assignment token below, rather than the other statements directly below it.

Code sample

<?php

declare(strict_types=1);

// phpcs:ignore
final class Test
{
    public const DEFAULT = 'default';
    public const SOS     = 'sos';
    public const HELP    = 'help';

    // phpcs:ignore
    protected static $thisIsAReallyLongVariableName = [
        self::DEFAULT  => 'DEFAULT',
        self::SOS => 'SOS',
        self::HELP => 'Help',
    ];
}

To reproduce
Steps to reproduce the behavior:

1. Create a file called test.php with the code sample above...
2. Run phpcs test.php ...
3. See error message displayed

  8 | ERROR | [x] Equals sign not aligned with surrounding
    |       |     assignments; expected 28 spaces but found 1
    |       |     space
    |       |     (Generic.Formatting.MultipleStatementAlignment.NotSame)
  9 | ERROR | [x] Equals sign not aligned with surrounding
    |       |     assignments; expected 2 spaces but found 5
    |       |     spaces
    |       |     (Generic.Formatting.MultipleStatementAlignment.NotSame)
 10 | ERROR | [x] Equals sign not aligned with surrounding
    |       |     assignments; expected 1 space but found 4
    |       |     spaces
    |       |     (Generic.Formatting.MultipleStatementAlignment.NotSame)

Expected behavior
No reported errors.

Versions (please complete the following information):

• OS: Ubuntu 20.10
• PHP: 7.4
• PHPCS: 3.6.0
• Standard: PSR2

Additional context
To clarify the issue, this throws no errors:

<?php

declare(strict_types=1);

// phpcs:ignore
final class Test
{
    public const DEFAULT                            = 'default';
    public const SOS  = 'sos';
    public const HELP = 'help';

    // phpcs:ignore
    protected static $thisIsAReallyLongVariableName = [
        self::DEFAULT  => 'DEFAULT',
        self::SOS => 'SOS',
        self::HELP => 'Help',
    ];
}

This also throws no errors:

<?php

declare(strict_types=1);

// phpcs:ignore
final class Test
{
    public const DEFAULX = 'default';
    public const SOS     = 'sos';
    public const HELP    = 'help';

    // phpcs:ignore
    protected static $thisIsAReallyLongVariableName = [
        self::DEFAULX  => 'DEFAULT',
        self::SOS => 'SOS',
        self::HELP => 'Help',
    ];
}

[jrfnl]

I've been looking into this issue.

A git bisect learns that it first surfaces with commit 2ba5393 in response to #3219.

That commit, however, did not cause the issue. Rather, it exposes an underlying issue related to #3336.

After PHP::tokenize(), the DEFAULT is still tokenized as T_DEFAULT. This causes the Tokenizer::recurseScopeMap() to assign it as the scope_opener to the ; semi-colon at the end of the constant declaration, with the class close curly brace being set as the scope_closer.
In the PHP::processAdditional() method, the DEFAULT is subsequently retokenized to T_STRING as it is preceded by a const keyword, but that is too late.

The scope_opener being set on the semi-colon is what is causing the errors to be displayed for the above code sample.

So, like #3336, this is a problem with reserved keywords being used as names in valid contexts, but still being tokenized as the reserved keyword by PHP. As discussed in #3020, the TOKEN_PARSE flag would solve this, but using it is not an option due to PHPCS 3.x still supporting PHP < 7.0, as well as that flag making the tokenizer parse error intolerant, so this will need to be solved differently at a PHPCS tokenizer level and needs to be solved in PHP::tokenize(), not PHP::processAdditional() as solving it in the latter still allows for the scope map to be incorrectly set.

[jrfnl]

@caseyjhol Thanks for reporting this. PR #3351 should fix this. Testing appreciated.

[gsherwood]

I confirmed PR #3351 does fix this bug (thanks @jrfnl). Thanks a lot for the bug report. The fix will be in 3.6.1.