Fixes #159. First attempt to replace the current IDN library with the one from https://github.com/TRowbotham/idna.

• [x] Modify code to be PHP 5.3 compatible
• [x] Port over tests
• [x] Port over build scripts

1. Add new constants: T_NAME_FULLY_QUALIFIED, T_NAME_RELATIVE, T_NAME_QUALIFIED, T_NULLSAFE_OBJECT_OPERATOR, T_ATTRIBUTE and T_MATCH.
2. Fix PhpToken::tokenize() result: 2.1. Implements T_NAME_RELATIVE and T_NAME_QUALIFIED tokens ((T_STRING T_NS_SEPARATOR)xN or (T_NS_SEPARATOR T_STRING)xN). 2.2. Implement T_NULLSAFE_OBJECT_OPERATOR token (T_STRING '?->' T_STRING) 2.3. Implement T_MATCH token 2.3. Implement T_ATTRIBUTE token

FWIW, today the update to symfony/polyfill-intl-idn v1.16 (from 1.15) just completely broke all my Guzzle usages. This is on a server running CentOS 6 (and therefore old ICU - 4.2.1?) and PHP 7.3

Composer noob trying to start a project with a boilerplate package that requires polyfill-php73 (among other things). I kept getting the error in the title of this issue. I finally deleted everything in the directory and tried to isolate this package to see if it was related to the myriad of other packages. Here's what I got:

composer require symfony/polyfill-php73
Using version ^1.11 for symfony/polyfill-php73
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing symfony/polyfill-php73 (v1.11.0): Loading from cache
Writing lock file
Generating autoload files

Installation failed, deleting ./composer.json.


  [RuntimeException]
  Could not scan for classes inside "/srv/www/wordpress-one/public_html/wp-content/plugins/inpsyde-nonces/vendor/symfony/polyfill-php73/Resources/stubs" which does not appear to be a fil
  e nor a folder


require [--dev] [--prefer-source] [--prefer-dist] [--no-progress] [--no-suggest] [--no-update] [--no-scripts] [--update-no-dev] [--update-with-dependencies] [--update-with-all-dependencies] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [--sort-packages] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--] [<packages>]...

composer -V shows: Composer version 1.8.6 2019-06-11 15:03:05

I don't know if I'm doing something wrong or not. I'm trying to do a project with PHP 7.2 so I don't think I even need this, but I'd like to use this particular boilerplate package to develop with. At any rate if someone could point me in the right direction for how to resolve this I'd be grateful. Thanks!

Zend Server tries to implement compatibility with apc by registering compatibility functions with the same name as the APC functions.

http://files.zend.com/help/Zend-Server-6/content/zend_data_cache_-_configuration_directives.htm

Specifically, the option is "zend_datacache.apc_compatibility". It looks like it gets aliased to zend_shm_cache_store, which mostly works. Unfortunately, it doesn't support the array form of apc_store(), so every call results in errors:

"apc_store() expects parameter 1 to be string, array given"

It looks like this is a problem that other projects have dealt with, and it looks like it's one that's been going on for 8 years or so, so I'm not expecting Zend to fix it anytime soon.

My inclination would be to add a check to see if the parameter to apcu_add() or apcu_store() is an array, and if so to call the apc function individually for each item in the array. It would maintain compatibility with APC, and fix the issues with Zend Server. It's a little bit of a hack, though, and I figured I'd ask before submitting a PR.

Alternatively, I could add support for Zend Data Cache to the Symfony Cache Component.

Hi,

In an encrypted environment, in a Windows PHP 7.3 or 7.4 project , we have this error :

production.ERROR: Class 'p\Php80' not found {"exception":"[object] (Error(code: 0): Class 'p\\Php80' not found at .\api\vendor\symfony\polyfill\src\Php80\bootstrap.php:32) [stacktrace] #00 ...\api\app\Helpers\Env.php(123): str_starts_with('', '...') #01 ...\api\app\Helpers\Env.php(142): App\Helpers\Env::decodeEnvPassword('', '...') #02 ...\api\config\database.php(44): App\Helpers\Env::env_password('...') #03 ...\api\vendor\laravel\lumen-framework\src\Application.php(688): unknown() #04 ...\api\vendor\laravel\lumen-framework\src\Application.php(662): Laravel\Lumen\Application->configure('database') #05 ...\api\vendor\laravel\lumen-framework\src\Application.php(410): Laravel\Lumen\Application->loadComponent('database', Array, 'db') #06 ...\api\vendor\laravel\framework\src\Illuminate\Container\Container.php(805): Laravel\Lumen\Application->Laravel\Lumen\{closure}(Object(Laravel\Lumen\Application), Array) #07 ...\api\vendor\laravel\framework\src\Illuminate\Container\Container.php(691): Illuminate\Container\Container->build(Object(Closure)) #08 ...\api\vendor\laravel\framework\src\Illuminate\Container\Container.php(637): Illuminate\Container\Container->resolve('db', Array) #09 ...\api\vendor\laravel\lumen-framework\src\Application.php(300): Illuminate\Container\Container->make('db', Array) #10 ...\api\vendor\laravel\lumen-framework\src\Application.php(778): Laravel\Lumen\Application->make('db') #11 ...\api\bootstrap\app.php(54): Laravel\Lumen\Application->withEloquent() #12 ...\api\public\index.php(14): unknown() #13 {main} "}

Any idea what cause this problem ?

Greetings.

<?php

var_dump(mb_strpos(null, 'a'));

should print to bool(false) and raise no errors (https://3v4l.org/YXq4M), because the mb_ functions all treat null as the empty string, by design.

On PHP 8, the symfony polyfill triggers a type error.

When extension is installed, the related polyfill is not need, but is still downloaded + bootstraped.

The idea is to provide composer meta-package (without code) to avoid that

{
  "name": "symfony/not-polyfill-intl",
  "require": {
    "ext-intl": "*"
  },
  "replace": {
    "symfony/polyfill-intl-grapheme": "*",
    "symfony/polyfill-intl-icu": "*",
    "symfony/polyfill-intl-idn": "*",
    "symfony/polyfill-intl-normalizer": "*",
  }
}

{
  "name": "symfony/not-polyfill-php73",
  "require": {
    "php": ">=7.3"
  },
  "replace": {
    "symfony/polyfill-php73": "*",
    "symfony/polyfill-php72": "*",
    "symfony/polyfill-php71": "*",
    "symfony/polyfill-php70": "*",
    "symfony/polyfill-php56": "*"
  }
}

users can just composer req symfony/not-polyfill-php73 to remove those un-needed packages.

WDYT?

I added a test in stubs classes to prevent php -l to fail on polyfills (errors like PHP Fatal error: Cannot declare class ArithmeticError, because the name is already in use)

• add test to lint polyfill files
• make lint test pass

It looks like the PHP8 behaviour for str_contains actually silently accepts a null value (casting it to the empty string), whereas the polyfill doesn't. See this comparison on 3v4l, where you can see that the polyfill throws a TypeError but PHP8 doesn't. The same is probably true for the other str methods, but I haven't confirmed it yet.

Happy to send a PR (possibly just easiest to remove the types from the params?)

We use the intl-idn package in TYPO3 CMS and it helps a lot! Thank you for providing such a package.

However there is one large TYPO3 hoster (having roughly 200.000 TYPO3 installations), where they have a messed up Server setup regarding to ICU version on their system. In short: They provide the php-intl extension, but do not define all constants as needed for PHP 7.2+. We had solved this issue in the past by a hard workaround, but with the update to polyfill-intl-idn 1.17.1 and 1.18.0 then (respective change) https://github.com/symfony/polyfill-intl-idn/commit/3bff59ea7047e925be6b7f2059d60af31bb46d6a (or https://github.com/symfony/polyfill/commit/f968149bedaaa9013d39fecd9cab1139aba1334a#diff-eaa55ac0b04a1928e5455b4f48efe417R14-R17) our setups don't work on the hoster anymore, as they clearly have a misconfiguration.

Still, the previous solution when not checking on the extension_loaded() was more robust for these kind of weird setups.

In any case, I'm (personally) fine if you decide to keep the extension_loaded() check in your library, but wanted to let you know that this actually is an issue for a lot of people. It would be great to know if you're able to fix it or planning to fix/revert the three lines or if we should find a workaround for ourselves in our project.

Hi, mb_check_encoding accepts an array of strings: https://3v4l.org/i5MBi

But Symfony\Polyfill\Mbstring\Mbstring::mb_check_encoding crashes with the same input:

Uncaught TypeError: preg_match(): Argument #2 ($subject) must be of type string, array given in /Users/ondrej/Development/phpstan/vendor/symfony/polyfill-mbstring/Mbstring.php:440
#0 /Users/ondrej/Development/phpstan/vendor/symfony/polyfill-mbstring/Mbstring.php(440): preg_match('//u', Array)
#1 /Users/ondrej/Development/phpstan/vendor/symfony/polyfill-mbstring/Mbstring.php(416): Symfony\Polyfill\Mbstring\Mbstring::mb_detect_encoding(Array, Array)
#2 /Users/ondrej/Development/phpstan/src/Type/Php/StrCaseFunctionsReturnTypeExtension.php(82): Symfony\Polyfill\Mbstring\Mbstring::mb_check_encoding(Array, 'UTF-8')

Tested with symfony/polyfill-mbstring v1.27.0.

Thanks :)

Hi,

With the polyfill, var_dump(mb_strlen(chr(254))) return 0. With the php8.0-mbstring extension, var_dump(mb_strlen(chr(254))) return 1;

versions : * v1.26.0

Thanks, Alex

Polyfill taken from PHP.Watch - PHP 8.2: New ini_parse_quantity function

Tries to mimic the native warnings with E_USER_WARNING errors, and overflow/underflow conditions by inspecting the int to float type change.

Hello,

I noticed that there is an incompatibility with the mbstring polyfill and PHP 8.1 / Alpine Linux, which breaks a lot of my projects as soon as the php81-mbstring is not installed, but php81-iconv is installed:

Example:

Warning: iconv(): Wrong encoding, conversion from "ASCII" to "UTF-8//IGNORE" is not allowed in phar:///var/www/localhost/htdocs/phpstan.phar/vendor/symfony/polyfill-mbstring/Mbstring.php on line 736

It looks like //IGNORE is not accepted since echo iconv('UTF-8', 'UTF-8', 'test'); works, while echo iconv('UTF-8', 'UTF-8//IGNORE', 'test'); doesn't

Take the following emoji for instance: 👩‍👩‍👦‍👦

This emoji consists of four different emojis glued together by Zero Width Joiner characters, as seen on https://emojipedia.org/family-woman-woman-boy-boy/.

When checking the length with grapheme_strlen(), it returns 1, while this library returns 4.

This is possibly due to a bug on the GRAPHEME_CLUSTER_RX regex.

This bug should only happen on PCRE_VERSION < 8.32, however, when combined with the bug #369 , it applies to all PCRE_VERSION that contains a date timestamp, which seems to be the default format.

Therefore, the grapheme_strlen function in this polyfill is likely to provide incorrect results, such as in this example:

Expected result grapheme_strlen('👩‍👩‍👦‍👦'):

The test is being conducted using the regex: \X

int(1)
int(1)
int(1)
int(1)

Actual result with the custom cluster grapheme_strlen('👩‍👩‍👦‍👦'):

The test is being conducted using the regex: (?:\r\n|(?:[ -~\x{200C}\x{200D}]|[ᆨ-ᇹ]+|[ᄀ-ᅟ]*(?:[가개갸걔거게겨계고과괘괴교구궈궤귀규그긔기까깨꺄꺠꺼께껴꼐꼬꽈꽤꾀꾜꾸꿔꿰뀌뀨끄끠끼나내냐냬너네녀녜노놔놰뇌뇨누눠눼뉘뉴느늬니다대댜댸더데뎌뎨도돠돼되됴두둬뒈뒤듀드듸디따때땨떄떠떼뗘뗴또똬뙈뙤뚀뚜뚸뛔뛰뜌뜨띄띠라래랴럐러레려례로롸뢔뢰료루뤄뤠뤼류르릐리마매먀먜머메며몌모뫄뫠뫼묘무뭐뭬뮈뮤므믜미바배뱌뱨버베벼볘보봐봬뵈뵤부붜붸뷔뷰브븨비빠빼뺘뺴뻐뻬뼈뼤뽀뽜뽸뾔뾰뿌뿨쀄쀠쀼쁘쁴삐사새샤섀서세셔셰소솨쇄쇠쇼수숴쉐쉬슈스싀시싸쌔쌰썌써쎄쎠쎼쏘쏴쐐쐬쑈쑤쒀쒜쒸쓔쓰씌씨아애야얘어에여예오와왜외요우워웨위유으의이자재쟈쟤저제져졔조좌좨죄죠주줘줴쥐쥬즈즤지짜째쨔쨰쩌쩨쪄쪠쪼쫘쫴쬐쬬쭈쭤쮀쮜쮸쯔쯰찌차채챠챼처체쳐쳬초촤쵀최쵸추춰췌취츄츠츼치카캐캬컈커케켜켸코콰쾌쾨쿄쿠쿼퀘퀴큐크킈키타태탸턔터테텨톄토톼퇘퇴툐투퉈퉤튀튜트틔티파패퍄퍠퍼페펴폐포퐈퐤푀표푸풔풰퓌퓨프픠피하해햐햬허헤혀혜호화홰회효후훠훼휘휴흐희히]?[ᅠ-ᆢ]+|[가-힣])[ᆨ-ᇹ]*|[ᄀ-ᅟ]+|[^\p{Cc}\p{Cf}\p{Zl}\p{Zp}])[\p{Mn}\p{Me}\x{09BE}\x{09D7}\x{0B3E}\x{0B57}\x{0BBE}\x{0BD7}\x{0CC2}\x{0CD5}\x{0CD6}\x{0D3E}\x{0D57}\x{0DCF}\x{0DDF}\x{200C}\x{200D}\x{1D165}\x{1D16E}-\x{1D172}]*|[\p{Cc}\p{Cf}\p{Zl}\p{Zp}])

int(1)
int(4)
int(1)
int(4)

When calling mb_convert_encoding() with $fromEncoding === 'HTML-ENTITIES', the polyfill does not return functionally equivalent strings to the native function. This is because mb_convert_encoding() uses html_entity_decode() when $fromEncoding === 'HTML-ENTITIES' and that function does not return characters for many numeric entities 0-31 and 127-159. For example:

<?php

require "vendor/symfony/polyfill-mbstring/Mbstring.php";

use Symfony\Polyfill\Mbstring as p;

for($i = 0; $i < 1024; $i++) {
	$string = "&#" . $i . ";";
	$mbstring = mb_convert_encoding($string, 'UTF-8', 'HTML-ENTITIES');
	$polyfill = p\Mbstring::mb_convert_encoding($string, 'UTF-8', 'HTML-ENTITIES');
	if($mbstring != $polyfill) {
		echo "Mismatch: $string - mbstring: $mbstring; polyfill: $polyfill\n";
	}
}

outputs:

Mismatch: � - mbstring: ; polyfill: �
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring:; polyfill: 
Mismatch:  - mbstring:
                            ; polyfill: 
Mismatch:  - mbstring:
                            ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring:  polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch: ' - mbstring: '; polyfill: '
Mismatch:  - mbstring: ; polyfill: 
Mismatch: € - mbstring: €; polyfill: €
Mismatch:  - mbstring: ; polyfill: 
Mismatch: ‚ - mbstring: ‚; polyfill: ‚
Mismatch: ƒ - mbstring: ƒ; polyfill: ƒ
Mismatch: „ - mbstring: „; polyfill: „
Mismatch: … - mbstring: …; polyfill: …
Mismatch: † - mbstring: †; polyfill: †
Mismatch: ‡ - mbstring: ‡; polyfill: ‡
Mismatch: ˆ - mbstring: ˆ; polyfill: ˆ
Mismatch: ‰ - mbstring: ‰; polyfill: ‰
Mismatch: Š - mbstring: Š; polyfill: Š
Mismatch: ‹ - mbstring: ‹; polyfill: ‹
Mismatch: Œ - mbstring: Œ; polyfill: Œ
Mismatch:  - mbstring: ; polyfill: 
Mismatch: Ž - mbstring: Ž; polyfill: Ž
Mismatch:  - mbstring: ; polyfill: 
Mismatch:  - mbstring: ; polyfill: 
Mismatch: ‘ - mbstring: ‘; polyfill: ‘
Mismatch: ’ - mbstring: ’; polyfill: ’
Mismatch: “ - mbstring: “; polyfill: “
Mismatch: ” - mbstring: ”; polyfill: ”
Mismatch: • - mbstring: •; polyfill: •
Mismatch: – - mbstring: –; polyfill: –
Mismatch: — - mbstring: —; polyfill: —
Mismatch: ˜ - mbstring: ˜; polyfill: ˜
Mismatch: ™ - mbstring: ™; polyfill: ™
Mismatch: š - mbstring: š; polyfill: š
Mismatch: › - mbstring: ›; polyfill: ›
Mismatch: œ - mbstring: œ; polyfill: œ
Mismatch:  - mbstring: ; polyfill: 
Mismatch: ž - mbstring: ž; polyfill: ž
Mismatch: Ÿ - mbstring: Ÿ; polyfill: Ÿ

While many of these are control characters (and the native function does return them), the single quote (dec 39) is particularly problematic.