Allow overriding the PHP 7.2 support for PREG_UNMATCHED_AS_NULL

[Seldaek]

cc @staabm

I am not sure if this is too ugly or too specific for you to care, but in composer/pcre I did build a compat layer for PREG_UNMATCHED_AS_NULL on PHP 7.2/7.3 - so it would be nice if I could enable this flag to get proper return types even on PHP 7.2/7.3

If it's too ugly I understand, and I'll live with it until Composer can drop 7.2 :)

[staabm]

I agree having impl specific feature toggles in phpstan-src looks fishy - especially for such an ancient php version. lets see what ondrey thinks about it

[Seldaek]

Yeah, I guess alternatively I could simply copy the code in composer/pcre 2.x, it's not that much and shouldn't change too often once stabilized

Edit: that might allow me to remove the conflict on older phpstan too I guess as a bonus..

[staabm]

Edit: that might allow me to remove the conflict on older phpstan too I guess as a bonus..

the RegexArrayShapeMatcher alone does not give you support in older phpstan-src versions. there are a few more parts - like the new *ParameterOutTypeExtension which is required.

---

lets wait for ondrej. he usually has a clear opinion on such things ;)

[staabm]

just alternative suggestion: instead of adding a new bool flag to the api, we might consider adding a new feature flag config switch in the .neon file doesn't make sense as different apis might be in use at the same time.

please don't adjust the PR until ondrej gave some insight though.

[ondrejmirtes]

I'm mostly in favour of this, but what about a custom flag that would be a public constant in RegexArrayShapeMatcher and that would be passed into int $flags? We just need to make sure we're not conflicting with existing PCRE flags.

[Seldaek]

Yeah that's a great idea to avoid polluting the arg list, I'll investigate.

[Seldaek]

Ok I think that's what you meant?

[staabm]

the phpdoc type needs a fix:

* @param int-mask<PREG_OFFSET_CAPTURE|PREG_UNMATCHED_AS_NULL>|null $flags

[Seldaek]

The highest in use currently is 256, so I chose 2048 to leave 512/1024 as gaps if PHP should add new constants there.

[Seldaek]

Somehow phpstan thinks it's an int<0, 2816> as that's the value on the right. Could be nice if it was smarter here but I guess bitwise use is rare enough that it's not worth that much time spent optimizing for them.

The var annotation fixed it though.

[ondrejmirtes]

Thank you!

[Seldaek]

Cool, implemented in composer/pcre@088f752 and it works great!