PHPCSStandards / PHP_CodeSniffer / 13166747594
78%
master: 79%

LAST BUILD BRANCH: feature/fixer-conflict/PSR12.Functions.ReturnTypeDeclaration
DEFAULT BRANCH: master
Ran
Jobs 8
Files 262
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 77.129%. Remained the same
13166747594

push

github

jrfnl 
PEAR/Squiz/InlineComment: document handling of emoji hash comments

Based on some rumblings on the interwebs, I've done some investigating.

It was basically claimed that the emoji keycap sign for the hash character could be used for hash comments.
Based on my investigation, this turns out to be **true**.
Technical explanation: as the emoji keycap sign is a combined unicode character of which the first codepoint is the `#` character, the PHP tokenizer will see whatever comes after as a comment and tokenize it as such.

In a follow-up message, it was claimed that using the emoji keycap sign for the hash character could also be used for attributes.
Based on my investigation, this (unsurprisingly) turns out to be **false**.
Technical explanation: for attributes, the `#` sign and the `[` bracket need to be next to each without any characters between them for the syntax to be recognized as the start of an attribute. This was implemented like so to keep the BC-break with hash comments as small as possible when attributes were introduced in PHP 8.0.
As the emoji keycap sign is a combined character (U+23 U+FE0F U+20E3) , there are multiple other codepoints between the `#` and the `[`, which means that this will not tokenizer as `T_ATTRIBUTE` in PHP and therefore shouldn't in PHPCS either.

For now, I'm just adding a test to both the PEAR and Squiz `InlineComment` sniffs to document how emoji-hash comments are handled by PHPCS.
I am aware that the fixer output is not "clean", i.e. it leaves the second and third code point of the emoji in place.

I did consider adding special handling in the fixers, but decided against this for the following reasons:
1. This is likely to be a rare edge case.
2. I suspect the most reliable way to handle this would require the `intl` extension to use `graphmeme` functions. I'm not inclined to make the `intl` extension a requirement for PHPCS at this time.
3. An alternative way to handle this could be via unicode escape codes, but... (continued)

19027 of 24669 relevant lines covered (77.13%)

76.27 hits per line

Jobs
ID Job ID Ran Files Coverage
1 os-windows-latest-php-8.4-custom-ini-false - 13166747594.1 262
2.6
 GitHub Action Run
2 os-ubuntu-latest-php-7.2-custom-ini-false - 13166747594.2 262
73.45
 GitHub Action Run
3 os-ubuntu-latest-php-8.4-custom-ini-false - 13166747594.3 262
75.62
 GitHub Action Run
4 cbf-os-ubuntu-latest-ubuntu-latest-php-7.2-custom-ini-false - 13166747594.4 262
0.82
 GitHub Action Run
5 os-ubuntu-latest-php-8.1-custom-ini-true - 13166747594.5 262
75.64
 GitHub Action Run
6 os-windows-latest-php-7.2-custom-ini-false - 13166747594.6 262
2.08
 GitHub Action Run
7 cbf-os-ubuntu-latest-ubuntu-latest-php-8.1-custom-ini-true - 13166747594.7 262
1.91
 GitHub Action Run
8 cbf-os-ubuntu-latest-ubuntu-latest-php-8.4-custom-ini-false - 13166747594.8 262
1.9
 GitHub Action Run
Source Files on build 13166747594