Re: [PHP-DEV] List of attributes

[Theodore Brown]

On Sat, Oct 31, 2020, at 5:06 AM, Rowan Tommins wrote:

> > This would be an artificial limitation on attributes to patch
> > over the inherent inconsistency of the grouped syntax for nested
> > attributes.
>
> There is no artificial limitation; there is a binary choice: does
> #[Foo] represent an object or a list with one item in? This is
> completely new syntax, so there is nothing for it to be inconsistent
> with other than itself.

It is very much an artificial limitation. Developers would be prevented
from declaring that an attribute must be passed a single attribute 
with a particular type as one of its parameters. This isn't a natural
or inherent limitation of attributes, but an artificial one in order
to try to make the `#[Attr1, Attr2]` grouped syntax usable with nested
attributes.

> I am arguing that having it represent a list with one item in is
> actually *more* consistent, because when you attach attributes to a
> declaration, they are always retrieved as a list.

That's not necessarily the case for nested attributes. A developer
may want to declare that an attribute constructor takes a single
attribute with a particular type as one of its arguments. Why should
PHP prevent this by only allowing a (possibly empty) list to be
passed? Again, this would be an artificial limitation that reduces
the flexibility and usefulness of nested attributes.

On Sat, Oct 31, 2020 at 7:38 PM Larry Garfield  wrote:

> Perhaps a naive question, but I'm missing the downside of:
> 
> #[Foo(Bar(name="baz"))]
> 
> #[Attribute]
> class Foo {
>   public function construct(public Bar $bar) {}
> }
> 
> class Bar {
>   public function construct(public string $name) {}
> }
> 
> Why is that not OK?  Someone mentioned it means you couldn't call a
> function there, but... that's not a huge problem because I can't
> imagine why you would.  If we really wanted to avoid that:
> 
> #[Foo(new Bar(name="baz"))]
>
> That would be unambiguous, if a bit ugly.

As I mentioned in my first email in this thread, there was an attempt
to do this back when the original `<<>>` attribute syntax was being
implemented. But this approach ran into difficulties since it would
require significant changes to constant expressions.

Even if someone finds a reasonable way to make such a syntax *work*,
it still has the downside of requiring a different syntax for top-
level and nested attributes (docblock annotations allow using the
same syntax for both). Moreover, re-purposing the syntax for function
calls or class instantiation is likely to cause confusion, since it
looks like the code is doing something other than what it actually
does (and of course it would prevent ever extending constant
expressions to support function calls or class instantiation).

One of my main motivations for proposing the `@@` shorter attribute
syntax was to avoid the complexity of grouped declarations and allow
using a single consistent syntax for both top level and nested
attributes. I fear that the change to the `#[]` syntax with grouping
will prevent PHP from getting a flexible and intuitive nested
attribute implementation, and devs will be forced to stick with
docblock annotations for these use cases.

Kind regards,  
Theodore

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP releases, OPcache + Jit bugs, and communication

[Marco Pivetta]

Hey Dan,



On Tue, Nov 24, 2020 at 9:48 PM Dan Ackroyd  wrote:

> Hi internals,
>
> Currently the PHP project doesn't have a particularly great way of
> letting users know when serious defects have been found in versions of
> PHP.
>
> My understanding is that this has been an issue before, when defects
> were found in OPcache. Due to OPcache incorrectly optimizing code,
> bugs could spontaneously appear anywhere in users code. As we had
> nothing in place, we didn't have a way of communicating 'the latest
> version is borked, avoid it'  Fortunately there were few incidents of
> this.
>
> However, the JIT is quite likely to have many similar issues, where
> either new issues, or regressions, could seriously affect the
> integrity of how data is processed in PHP applications.
>
> I'd like to suggest that this could be improved by having some machine
> readable data somewhere (see example below), that contains a list of
> known critical issues that people should know about before upgrading
> to a particular version of PHP.
>
> This would at least allow people to either hold off on upgrading from
> a version that works, to a known bad version, as well as do things
> like alert their ops team of investigating whether a newly found issue
> could be affecting their programs, and it might be appropriate for
> them to revert to a previous version of  PHP.
>
> Thoughts? And does anyone know of any projects that already do this,
> so we can be inspired by their best practices?
>
> cheers
> Dan
> Ack
>
> btw before anyone suggests "why don't we just have more releases?",
> PHP is mostly distributed through package managers on a fixed
> schedule. Switching to an ad-hoc schedule would be a huge amount of
> work for many people, and doesn't like a reasonable thing to do.
>
>
> Example of data
> -
> [
> {
> "version": "8.0.1",
> "issues": [
> {
> "link": "https:\/\/bugs.php.net\/bug.php?id=12345",
> "affects": "jit"
> }
> ]
> },
> {
> "version": "8.0.0",
> "issues": [
> {
> "link": "https:\/\/bugs.php.net\/bug.php?id=12345",
> "affects": "opcache"
> }
> ]
> }
> ]
>
> The 'affects' entry could be a comma separated list of things such as:
>
> jit - the JIT
> opcache - opcache
> php - the core engine with/without JIT or OPcache.
> security - known security flaws that of a severity that justify an
> urgent upgrade
>

An rss/atom feed with affected version ranges (can be added via XSD, I
suppose) would be fantastic: I'd factor it into `roave/security-advisories`
ASAP, if there was a way to have such a thing :-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] PHP releases, OPcache + Jit bugs, and communication

[Larry Garfield]

On Tue, Nov 24, 2020, at 2:47 PM, Dan Ackroyd wrote:
> Hi internals,
> 
> Currently the PHP project doesn't have a particularly great way of
> letting users know when serious defects have been found in versions of
> PHP.
> 
> My understanding is that this has been an issue before, when defects
> were found in OPcache. Due to OPcache incorrectly optimizing code,
> bugs could spontaneously appear anywhere in users code. As we had
> nothing in place, we didn't have a way of communicating 'the latest
> version is borked, avoid it'  Fortunately there were few incidents of
> this.
> 
> However, the JIT is quite likely to have many similar issues, where
> either new issues, or regressions, could seriously affect the
> integrity of how data is processed in PHP applications.
> 
> I'd like to suggest that this could be improved by having some machine
> readable data somewhere (see example below), that contains a list of
> known critical issues that people should know about before upgrading
> to a particular version of PHP.
> 
> This would at least allow people to either hold off on upgrading from
> a version that works, to a known bad version, as well as do things
> like alert their ops team of investigating whether a newly found issue
> could be affecting their programs, and it might be appropriate for
> them to revert to a previous version of  PHP.
> 
> Thoughts? And does anyone know of any projects that already do this,
> so we can be inspired by their best practices?
> 
> cheers
> Dan
> Ack
> 
> btw before anyone suggests "why don't we just have more releases?",
> PHP is mostly distributed through package managers on a fixed
> schedule. Switching to an ad-hoc schedule would be a huge amount of
> work for many people, and doesn't like a reasonable thing to do.
> 
> 
> Example of data
> -
> [
> {
> "version": "8.0.1",
> "issues": [
> {
> "link": "https:\/\/bugs.php.net\/bug.php?id=12345",
> "affects": "jit"
> }
> ]
> },
> {
> "version": "8.0.0",
> "issues": [
> {
> "link": "https:\/\/bugs.php.net\/bug.php?id=12345",
> "affects": "opcache"
> }
> ]
> }
> ]
> 
> The 'affects' entry could be a comma separated list of things such as:
> 
> jit - the JIT
> opcache - opcache
> php - the core engine with/without JIT or OPcache.
> security - known security flaws that of a severity that justify an
> urgent upgrade

That was essentially the idea behind the FIG's PSR-9:

https://github.com/php-fig/fig-standards/blob/master/proposed/security-disclosure-publication.md

It unfortunately never really went anywhere, but I thought it was a good idea.  
There's some links there to some prior art we were drawing from, or planning to 
draw from.  The idea was to allow projects to publish a link to a feed of 
security releases in their composer.json, and then Composer (or a plugin) could 
audit your dependencies and tell you if one of them was busted.

My ideal was an Atom feed, as then it's compatible with pub/sub, but not 
everyone agreed with me about that. :-)

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP releases, OPcache + Jit bugs, and communication

[Dan Ackroyd]

Hi internals,

Currently the PHP project doesn't have a particularly great way of
letting users know when serious defects have been found in versions of
PHP.

My understanding is that this has been an issue before, when defects
were found in OPcache. Due to OPcache incorrectly optimizing code,
bugs could spontaneously appear anywhere in users code. As we had
nothing in place, we didn't have a way of communicating 'the latest
version is borked, avoid it'  Fortunately there were few incidents of
this.

However, the JIT is quite likely to have many similar issues, where
either new issues, or regressions, could seriously affect the
integrity of how data is processed in PHP applications.

I'd like to suggest that this could be improved by having some machine
readable data somewhere (see example below), that contains a list of
known critical issues that people should know about before upgrading
to a particular version of PHP.

This would at least allow people to either hold off on upgrading from
a version that works, to a known bad version, as well as do things
like alert their ops team of investigating whether a newly found issue
could be affecting their programs, and it might be appropriate for
them to revert to a previous version of  PHP.

Thoughts? And does anyone know of any projects that already do this,
so we can be inspired by their best practices?

cheers
Dan
Ack

btw before anyone suggests "why don't we just have more releases?",
PHP is mostly distributed through package managers on a fixed
schedule. Switching to an ad-hoc schedule would be a huge amount of
work for many people, and doesn't like a reasonable thing to do.


Example of data
-
[
{
"version": "8.0.1",
"issues": [
{
"link": "https:\/\/bugs.php.net\/bug.php?id=12345",
"affects": "jit"
}
]
},
{
"version": "8.0.0",
"issues": [
{
"link": "https:\/\/bugs.php.net\/bug.php?id=12345",
"affects": "opcache"
}
]
}
]

The 'affects' entry could be a comma separated list of things such as:

jit - the JIT
opcache - opcache
php - the core engine with/without JIT or OPcache.
security - known security flaws that of a severity that justify an
urgent upgrade

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Draft - Closure self reference

[Dan Ackroyd]

Sara Golemon wrote:
> looks a bit... ugly? weird? surprising?

I had the same initial reaction, and was going to tell David what I
thought of the suggestion. But after a couple of days, I was unable to
actually articulate what I didn't like it, so think I was just having
a gut reaction to something I hadn't seen before, and so wasn't used
to seeing.

Sara Golemon wrote:
> That's a lot of... stuff

Yeah, but it's a really rare use-case for a closure to need to be able
to reference itself, so I think it's probably fine to have some
verbosity around "this closure is doing something quite unusual".

I personally think any of:

function (... $args) as $lambda: returnType use ($captures...) {}
function (... $args): returnType as $lambda use ($captures...) {}
function (... $args): returnType use ($captures...) as $lambda {}

would be fine and various 'my aesthetic choice is objectively the
best' arguments, could be made for any of them.

David Rodrigues wrote:
> I ended up preferring this last option.

I prefer the others as I think they are more deliberate syntax (i.e.
don't look like a typo), avoid confusion around why can't normal
functions be declared with leading $'s, and almost certainly would be
easier to search for what they are. e.g. "php closure as variable"

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Dmitry Stogov]

On Tue, Nov 24, 2020 at 6:14 PM Sara Golemon  wrote:

> On Tue, Nov 24, 2020 at 8:55 AM Sara Golemon  wrote:
>
>> Given that the JIT is enabled by default, I'm tempted to add another RC
>> and delay the release.
>>
>>
> As Niki just helpfully pointed out; My understanding of the JIT's setting
> on 8.0 is wrong.  It's "on", but with a 0-sized buffer, so it's effectively
> disabled.
> #1 I feel so much more secure in this whole release than I did five
> minutes ago. No offence. :)
> #2 We can afford to be a little lax on pulling in those cherry-picks.
>
> So now the question is what is the impact of (not) pulling them into the
> release at the literal last minute.
> On the one hand, by the book, this is too late for a non-security fix.  On
> the other hand, this is .0, and it's impacting a not-enabled-by-default
> path, so we can be more generous.
>
>

I think many people are going to try JIT in PHP-8.0.0. The last commits fix
incorrect behavior of JIT generated code on some edge cases. e.g. wrong
reference-counting and following use-after-free on PHPUnit tests. Releasing
PHP-8.0.0 with already fixed bugs would cause false reports. On the other
hand the risk of these commits is minimal.

Thanks. Dmitry.


> Right now I'm inclined to pull them in, but I'll wait a few hours for
> anyone who wishes to object. (It's still only 9am here :p )
>
> -Sara
>

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Sara Golemon]

On Tue, Nov 24, 2020 at 10:27 AM Dmitry Stogov 
wrote:
> I think, new RC is not necessary.
> These commits only affect JIT. They fix the recently found problems and
don't show any degradation.
>

Good enough for me. I'll pull 'em up and cut in the next couple hours.

-Sara

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Dmitry Stogov]

Hi Sara,

On Tue, Nov 24, 2020 at 5:56 PM Sara Golemon  wrote:

> On Tue, Nov 24, 2020 at 12:35 AM Dmitry Stogov 
> wrote:
>
>> I finally fixed all the known JIT related issues and made the PHP-8.0
>> build "green".
>>
>>
>> https://dev.azure.com/phpazuredevops/PHP/_build/results?buildId=13088=results
>>
>> Please, cherry-pick the following 5 commits into PHP-8.0.0.
>>
>> c8df28d276c25c6f5ad0f1ab2727804b32be8cfe
>> c0d1dbcb432f65d09f1c88cc368aa89eb5f067f4
>> 4cf3da73839b1ef3ab1fc8f74aee3a00237ad6b5
>> 586ccfdfd5179336dcf3719577b8258e55e7d76e
>> 337d2af6ca50a52864034446d863331cbc61885e
>>
>>>
>>>
> Hi Dmitry, that's great news.
>
> Given that the JIT is enabled by default, I'm tempted to add another RC
> and delay the release.
> As the person who did this work, can you reassure my worries and tell me
> that's not needed?
> The good news is that none of these commits look particularly complex.
>

I think, new RC is not necessary.
These commits only affect JIT. They fix the recently found problems and
don't show any degradation.

Thanks. Dmitry.




>
> -Sara
>
> c8df28d276 Fixed 32-bit JIT
> c0d1dbcb43 Fixed incorrect TRACE_FRAME_MASK_NESTED flag setting
> 4cf3da7383 Keep value of register before possible side exit
> 586ccfdfd5 Fixed use-after-free in PHPUnit tests
> 337d2af6ca zend_jit_trace_stack_frame.stack can't be NULL
>

Re: [PHP-DEV] Renaming on of the XML opaque objects for consistency

[tyson andre]

> I know this is *literally* hours before the GA tag, but I just realized
> that when introducing opaque objects during the resource to object
> conversion the XMLWriter and XMLParser extensions don't use the same casing
> as the classes are named XmlParser and XMLWriter
> 
> Should we rename one of them for consistency just before GA is tagged or
> let it be?

I'd be in favor of XMLParser to match XMLReader, XMLWriter, and 
SimpleXMLElement/SimpleXMLIterator.

Cheers,
-- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Sara Golemon]

On Tue, Nov 24, 2020 at 8:55 AM Sara Golemon  wrote:

> Given that the JIT is enabled by default, I'm tempted to add another RC
> and delay the release.
>
>
As Niki just helpfully pointed out; My understanding of the JIT's setting
on 8.0 is wrong.  It's "on", but with a 0-sized buffer, so it's effectively
disabled.
#1 I feel so much more secure in this whole release than I did five minutes
ago. No offence. :)
#2 We can afford to be a little lax on pulling in those cherry-picks.

So now the question is what is the impact of (not) pulling them into the
release at the literal last minute.
On the one hand, by the book, this is too late for a non-security fix.  On
the other hand, this is .0, and it's impacting a not-enabled-by-default
path, so we can be more generous.

Right now I'm inclined to pull them in, but I'll wait a few hours for
anyone who wishes to object. (It's still only 9am here :p )

-Sara

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Sara Golemon]

On Tue, Nov 24, 2020 at 12:35 AM Dmitry Stogov 
wrote:

> I finally fixed all the known JIT related issues and made the PHP-8.0
> build "green".
>
>
> https://dev.azure.com/phpazuredevops/PHP/_build/results?buildId=13088=results
>
> Please, cherry-pick the following 5 commits into PHP-8.0.0.
>
> c8df28d276c25c6f5ad0f1ab2727804b32be8cfe
> c0d1dbcb432f65d09f1c88cc368aa89eb5f067f4
> 4cf3da73839b1ef3ab1fc8f74aee3a00237ad6b5
> 586ccfdfd5179336dcf3719577b8258e55e7d76e
> 337d2af6ca50a52864034446d863331cbc61885e
>
>>
>>
Hi Dmitry, that's great news.

Given that the JIT is enabled by default, I'm tempted to add another RC and
delay the release.
As the person who did this work, can you reassure my worries and tell me
that's not needed?
The good news is that none of these commits look particularly complex.

-Sara

c8df28d276 Fixed 32-bit JIT
c0d1dbcb43 Fixed incorrect TRACE_FRAME_MASK_NESTED flag setting
4cf3da7383 Keep value of register before possible side exit
586ccfdfd5 Fixed use-after-free in PHPUnit tests
337d2af6ca zend_jit_trace_stack_frame.stack can't be NULL

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Christoph M. Becker]

On 24.11.2020 at 03:40, Christopher Jones wrote:

> On 20/11/20 1:50 am, Sara Golemon wrote:
>
>> I've just cut the release branch for PHP-8.0.0 final which will be
>> released
>> in one week on 26 Nov.  Minor bug fixes can continue to be merged via the
>> PHP-8.0 branch for inclusion in 8.0.1, but 8.0.0 will be precisely what
>> 8.0.0RC5 contained unless serious issues are encountered.
>
> What is the status of Windows builds?
>
> In particular who can I work with to get the build to use updated Oracle
> client libraries for the OCI8 extension in the PHP bundle and the
> upcoming OCI8 3.0 release on PECL?  I.e. drop building with 11g and add
> 19c?

Well, I can update the OCI8 SDK on the build machine (assuming there are
no licensing issues), and roll a snapshot build (assuming that there are
no incompatibilities), but I wouldn't be able to run any tests.

Christoph

> Fine print: Oracle 19 is a long-term release.  Using Oracle Client 19c
> libraries lets OCI8 connect to Oracle DB 11.2 or later.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Renaming on of the XML opaque objects for consistency

[Claude Pache]

Since class names are case-insensitive, and since `XmlParser` is new as of PHP 
8.0, I guess that there is not much problems in correcting the canonical casing 
of `XmlParser` into `XMLParser`? Count it as a last-minute bugfix.

—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php