Re: [PHP-DEV] How to debug a segmentation fault?

On Tue, Jan 28, 2020 at 5:29 PM Benjamin Morel wrote: > Hi internals, > > I'm encountering a SIGSEGV in PHP-FPM on PHP 7.4.2 in a Symfony app. The > bug seems to happen during the rendering of a Twig template; this makes it > hard for me to pinpoint the code that triggers the segfault. > > Could

Re: [PHP-DEV] Operator overloading for userspace objects

On Wed, Jan 29, 2020 at 12:14 AM wrote: > Hello everybody, > > > > the last days I have experimented a bit with operator overloading in > userspace classes (redefing the meaning of arithmetic operations like +, -, > *, etc. for your own classes). > > This could be useful for different libraries w

[PHP-DEV] [VOTE] Variable syntax tweaks

Hi internals, As the last RFC for the day, I've opened voting on https://wiki.php.net/rfc/variable_syntax_tweaks. The vote will stay open until 2020-02-11. Regards, Nikita

[PHP-DEV] [VOTE] Static return type

Hi internals, I've opened voting on the "static" return type RFC: https://wiki.php.net/rfc/static_return_type Voting closes on 2020-02-11. Regards, Nikita

[PHP-DEV] [VOTE] Allow ::class on objects

Hi internals, I've opened the vote on https://wiki.php.net/rfc/class_name_literal_on_object.Voting closes 2020-02-11. Regards, Nikita

Re: [PHP-DEV] [RFC] "use global functions/consts" statement

On Mon, Jan 27, 2020 at 3:43 PM tyson andre wrote: > > This would be a compile error right now though, because we don't allow > "use"d symbols and declarations to clash. > > As I surprisingly discovered when implementing the RFC, they don't clash. > The PHP interpreter has a special case where it

[PHP-DEV] Re: [RFC] Variable syntax tweaks

On Tue, Jan 7, 2020 at 11:23 AM Nikita Popov wrote: > Hi internals, > > I'd like to propose a small RFC, which addresses a few minor issues that > have not been handled by the original "uniform variable syntax" RFC: > > https://wiki.php.net/rfc/variable_syntax_

[PHP-DEV] Re: [RFC] Allow ::class on objects

On Thu, Jan 9, 2020 at 11:27 AM Nikita Popov wrote: > Hi internals, > > Another small RFC, to allow $object::class syntax: > > https://wiki.php.net/rfc/class_name_literal_on_object > > Regards, > Nikita > Heads up: I plan to start voting on this tomorrow. I'

[PHP-DEV] Re: [RFC] Static return type

On Wed, Jan 8, 2020 at 12:42 PM Nikita Popov wrote: > Hi internals, > > I would like to propose the following RFC, which allows using "static" as > a return type: > > https://wiki.php.net/rfc/static_return_type > > While I'm personally not a fan of late

Re: [PHP-DEV] WeakMap vs PECL WeakMap

; had lead the RFC > author, Joe Watkins, to rename WeakRef to WeakReference to avoid conflicts. > > However, the latest addition from Nikita Popov, WeakMap > <https://wiki.php.net/rfc/weak_maps>, did not take the same argument into > account, therefore conflicting wi

Re: [PHP-DEV] Union types | true pseudo-type

On Mon, Jan 20, 2020 at 6:30 PM Benjamin Morel wrote: > Hi internals, > > I'd like to bring back the topic of supporting "true" as a type in PHP 8 > union types. > Now that the RFC has been > successfully voted, I'd like to revive the discussion about add

Re: [PHP-DEV] [RFC] "use global functions/consts" statement

On Sun, Jan 26, 2020 at 10:37 PM tyson andre wrote: > > and that you have to explicitly say that you use the current namespace > for that name: > > > > > declare(function_and_const_lookup='global'); > > namespace MyNS; > > use function MyNS\foo; > > // or, equivalently: use function namespace\fo

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

On Wed, Jan 22, 2020 at 4:47 PM Nicolas Grekas wrote: > Hello everyone, > > as announced last week, I'm officially opening a discussion for adding a > "Stringable" interface to PHP 8. > > The RFC and its rationale are presented here as required: > https://wiki.php.net/rfc/stringable > > The patch

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

On Fri, Jan 24, 2020 at 6:58 PM tyson andre wrote: > > I like the idea of using a meaningful value here, but think that this > > should be using a string, i.e. > declare(function_and_const_lookup='global') > > rather than declare(function_and_const_lookup=global). Currently > declare() > > syntax

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

On Sat, Jan 18, 2020 at 11:53 PM tyson andre wrote: > > I'd much rather have something like: > > > > declare(ambiguous_element_lookup=0) > > > > declare(ambiguous_element_lookup=off) > > Aside: declare(unambiguous_element_lookup=1) is probably a better choice > than my first choice of (disable_am

Re: [PHP-DEV] Adding TypeError and ValueError to count() function

l or a company can't pursue code upgrade before version update? > Please don't be rude. Nikita On Tue, Jan 21, 2020, 8:41 PM Philip Hofstetter > wrote: > >> Hi, >> >> >> On Tue, Jan 21, 2020 at 6:17 PM Nikita Popov >> wrote: >> >> > &g

Re: [PHP-DEV] Adding TypeError and ValueError to count() function

On Wed, Jan 8, 2020 at 1:23 PM Björn Larsson wrote: > Den 2020-01-07 kl. 21:57, skrev George Peter Banyard: > > Greetings internals, > > > > I would like your input on adding TypeError and ValueError exceptions > > to the count() function in respect to the Consistent type errors for > > internal

Re: [PHP-DEV] Typed array properties V2

On Fri, Jan 17, 2020 at 8:51 AM Aran Reeks wrote: > Hi Internals, > > I'd like to kick off a conversation to capture everyone else's thoughts on > tweaking / improving typed properties for arrays (for a PHP 8.x release). > > With all the work done lately to greatly improve the type support in PHP

Re: [PHP-DEV] Warn when declaring required parameter after optional one

On Sat, Jan 11, 2020 at 2:35 PM Niklas Keller wrote: > Hi Nikita, > > while this is a rather small change, it has quite some BC impact, as > not all old code has been adjusted to run on PHP 7.1+ only using > nullable types. > > I'd like to see an RFC with a vote for this. > > Regards, > Niklas >

Re: [PHP-DEV] [RFC] Variable syntax tweaks

On Thu, Jan 16, 2020 at 10:12 AM Claude Pache wrote: > > > > Le 7 janv. 2020 à 11:23, Nikita Popov a écrit : > > > > Hi internals, > > > > I'd like to propose a small RFC, which addresses a few minor issues that > > have not been handle

Re: [PHP-DEV] Who are the current eligible voters?

On Thu, Jan 16, 2020 at 3:45 PM Jan Ehrhardt wrote: > "Christoph M. Becker" in php.internals (Thu, 16 Jan 2020 14:16:21 > +0100): > >On 16.01.2020 at 13:18, Jan Ehrhardt wrote: > > > >> And I still cannot vote. This discussion prompted me to request a > >> password. I got a DokuWiki password, but

Re: [PHP-DEV] Who are the current eligible voters?

On Wed, Jan 15, 2020 at 9:03 PM Paul M. Jones wrote: > > > > On Jan 15, 2020, at 13:21, Ben Ramsey wrote: > > > > Everyone with a php.net account is able to vote. The public list is > here: https://people.php.net/ > > I don't think that's *quite* the case? As has been noted elsewhere, the > rule

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

On Tue, Jan 14, 2020 at 7:27 PM tyson andre wrote: > > This RFC proposes to support an opt-in "use global functions/consts;" > statement > > to disable PHP's check for the function/const in the current namespace > before falling back to the global namespace. > > > > https://wiki.php.net/rfc/use_g

Re: [PHP-DEV] [RFC] Allow ::class on objects

On Thu, Jan 9, 2020 at 9:49 PM Nicolas Grekas wrote: > > > $fooClass = Foo::class; >> > echo $foo::class; // TypeError b/c string? >> >> Yes, at least per the current proposal. Whether to allow this is listed as >> an open question. >> > > I missed that part! > > If it could return `str

Re: [PHP-DEV] [RFC] Allow ::class on objects

On Thu, Jan 9, 2020 at 3:28 PM Ralph Schindler wrote: > > > Another small RFC, to allow $object::class syntax: > > > > https://wiki.php.net/rfc/class_name_literal_on_object > > Hi Nikita, > > Glad to see enhancements to ::class. Open questions, given: > > > class Foo {} > > $foo = new F

Re: [PHP-DEV] [RFC] Static return type

On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins wrote: > On Thu, 9 Jan 2020 at 14:23, Andreas Hennings wrote: > > > > However, $this is not a real type, and it is unclear what the advantage > > of specifying $this rather than static would be from a type system level > > perspective. > > > > Perhaps

[PHP-DEV] Properly validate abstract methods in traits

Hi internals, I've prepared https://github.com/php/php-src/pull/5068 to fix validation of abstract methods inside traits for PHP 8. To provide some context, the situation is currently pretty weird... when you add an abstract method in a trait, you obviously do that because the trait requires that

Re: [PHP-DEV] Warn when declaring required parameter after optional one

s deprecation and later removal seem to be preferred by multiple people, I've changed the PR to implementation that instead. Nikita > > Am 09.01.2020 um 13:27 schrieb Nikita Popov : > > > > Hi internals, > > > > I've created https://github.com/php/ph

[PHP-DEV] Warn when declaring required parameter after optional one

Hi internals, I've created https://github.com/php/php-src/pull/5067 to make code like function test($foo = null, $bar) {} throw a warning: Warning: Required parameter $bar follows optional parameter Historically, having an "optional" parameter before a required one was useful for poor

Re: [PHP-DEV] zend_call_method with arguments passed by reference

have > nothing to copy back manually. > fci.params *should* contain the changed parameters after the call, at least assuming no_separation=0. It's not clear to me under what circumstances that wouldn't work. Nikita > -Original Message- > From: Nikita Popov > S

Re: [PHP-DEV] What to do with "$array[foobar]"?

On Thu, Jan 9, 2020 at 12:12 PM Rowan Tommins wrote: > On Thu, 9 Jan 2020 at 10:48, Nikita Popov wrote: > > > PHP has a couple of legacy string interpolation syntaxes, the most > > egregious being "$array[foobar]". The issue with this syntax is that the > > ar

[PHP-DEV] What to do with "$array[foobar]"?

Hi internals, PHP has a couple of legacy string interpolation syntaxes, the most egregious being "$array[foobar]". The issue with this syntax is that the array key is not quoted, is required to be not quoted and is silently accepted. We've been fighting back against unquoted strings for a long ti

[PHP-DEV] [RFC] Allow ::class on objects

Hi internals, Another small RFC, to allow $object::class syntax: https://wiki.php.net/rfc/class_name_literal_on_object Regards, Nikita

Re: [PHP-DEV] zend_call_method with arguments passed by reference

On Wed, Jan 8, 2020 at 3:59 PM mdolezal.noctuint.cz via internals < internals@lists.php.net> wrote: > Hello, > > I hope this is the appropriate mailing list, please redirect me to better > please if required. > > > > I am currently rewriting our PHP extension from PHP5 to PHP7. > > To call PHP met

[PHP-DEV] [RFC] Static return type

Hi internals, I would like to propose the following RFC, which allows using "static" as a return type: https://wiki.php.net/rfc/static_return_type While I'm personally not a fan of late static binding, we do support it and people do use it quite heavily, so I think we should also support it in r

Re: [PHP-DEV] [RFC] Variable syntax tweaks

On Tue, Jan 7, 2020 at 11:43 AM Rowan Tommins wrote: > On Tue, 7 Jan 2020 at 10:23, Nikita Popov wrote: > > > I'd like to propose a small RFC, which addresses a few minor issues that > > have not been handled by the original "uniform variable syntax" RFC:

[PHP-DEV] [RFC] Variable syntax tweaks

Hi internals, I'd like to propose a small RFC, which addresses a few minor issues that have not been handled by the original "uniform variable syntax" RFC: https://wiki.php.net/rfc/variable_syntax_tweaks This is all about edge cases of edge cases, of course. I think the only part here that is no

Re: [PHP-DEV] Inconsistent class behavior and undocumented(?) BC change

On Mon, Jan 6, 2020 at 7:18 PM Larry Garfield wrote: > On Mon, Jan 6, 2020, at 5:16 AM, Nikita Popov wrote: > > > Others have already explained why constructors are exempted from LSP > > checks, so let me reply to your other point... > > > > I believe that your exa

Re: [PHP-DEV] Inconsistent class behavior and undocumented(?) BC change

On Sun, Dec 8, 2019 at 1:29 AM Larry Garfield wrote: > I am not sure if this is a bug, a feature behaving in a desired but > confusing way, or a feature behaving in a confusing and thus undesireable > way. I am therefore reporting it here in order to defer to those who know > the answer to such

Re: [PHP-DEV] Ensure correct signatures for PHP magic methods

On Sun, Jan 5, 2020 at 6:44 PM Gabriel Caruso wrote: > Hello Internals, > > I have a PR proposing to start checking the signatures for PHP magic > methods in the next major version of PHP: > https://github.com/php/php-src/pull/4177. The idea for this PR came from > https://bugs.php.net/bug.php?id

Re: [PHP-DEV] Autoloading functions/consts without a performance impact

On Fri, Jan 3, 2020 at 12:22 PM Rasmus Schultz wrote: > On Fri, Jan 3, 2020 at 10:35 AM Nikita Popov wrote: > >> On Fri, Jan 3, 2020 at 2:51 AM tyson andre >> wrote: >> >> > After a quick search, it turns out I've mostly reinvented >> > h

Re: [PHP-DEV] Autoloading functions/consts without a performance impact

On Fri, Jan 3, 2020 at 2:51 AM tyson andre wrote: > After a quick search, it turns out I've mostly reinvented > https://wiki.php.net/rfc/autofunc which I hadn't remembered. > The `spl_autoload_*()` changes it mentions is what I had in mind > > There's been changes to php since then, it's been 7 y

[PHP-DEV] Re: [VOTE] WeakMap

On Wed, Dec 18, 2019 at 9:47 AM Nikita Popov wrote: > Hi internals, > > I've opened voting on the WeakMap proposal: > https://wiki.php.net/rfc/weak_maps > The WeakMap proposal has been accepted unanimously with 25 votes in favor. Regards, Nikita

Re: [PHP-DEV] XOAUTH2 support in PHP IMAP

On Wed, Dec 25, 2019 at 7:11 PM FreeScout wrote: > > Hi Team! > > Could you please take a look at > https://github.com/google/gmail-oauth2-tools/issues/18 > > What do you think? Will it be possible to add XOAUTH2 support to PHP > IMAP extension? > > Thanks > The IMAP extension is based on a C li

Re: [PHP-DEV] Allowing variable strings to be defined for a string offset

On Mon, Dec 16, 2019 at 12:21 PM Claude Pache wrote: > > > > Le 16 déc. 2019 à 10:58, George Peter Banyard a écrit > : > > > > Greetings internals, > > > > I'm here to get internals's opinion about allowing a string offset to be > > replaced with arbitrary strings. > > > > Since forever strings

[PHP-DEV] [VOTE] WeakMap

Hi internals, I've opened voting on the WeakMap proposal: https://wiki.php.net/rfc/weak_maps Regards, Nikita

Re: [PHP-DEV] Re: [RFC] Add WeakMap

On Mon, Dec 16, 2019 at 10:19 AM Dennis Birkholz wrote: > On 12.12.19 18:13, Nikita Popov wrote: > > On Tue, Dec 10, 2019 at 12:03 PM Dennis Birkholz < > p...@dennis.birkholz.biz> > > wrote: > >> But my just want to repeat my main concern: buildin > >>

Re: [PHP-DEV] Re: [RFC] Add WeakMap

On Tue, Dec 10, 2019 at 12:03 PM Dennis Birkholz wrote: > Hi Nikita, > > On 06.12.19 11:29, Nikita Popov wrote: > > Could you provide some context on why you think serialization support for > > WeakMap is important? As weak maps are essentially caching structures, > &g

Re: [PHP-DEV] [RFC][Accepted] Password Mechanism Registry

On Tue, Nov 20, 2018 at 8:05 PM Sara Golemon wrote: > https://wiki.php.net/rfc/password_registry has been accepted > unanimously 21:0 with the supplemental vote on maintaining BC for the > integer based mechanism parameters passing 19:1. > > Implementation will be forthcoming. > > -Sara > Hey Sa

Re: [PHP-DEV] Re: [RFC] Add WeakMap

On Thu, Dec 5, 2019 at 6:09 PM Dennis Birkholz wrote: > Hi Nikita, > > Am 04.12.19 um 19:50 schrieb Nikita Popov: > >> This RFC proposes to add a native WeakMap type for PHP 8: > >> https://wiki.php.net/rfc/weak_maps > > > > Any comments on this propos

[PHP-DEV] Re: [RFC] Add WeakMap

On Mon, Nov 4, 2019 at 2:22 PM Nikita Popov wrote: > Hi internals, > > This is a follow up to the addition of WeakReference in PHP 7.4. > WeakReference is an important primitive, but what people usually really > need are weak maps, which can't be implemented on top of WeakR

Re: [PHP-DEV] PHP 7.4.0 Released!

Who is running @php_official on Twitter? I'd really prefer to retweet a release announcement from there, but they always seem to be lagging days behind. On Thu, Nov 28, 2019 at 6:36 PM Derick Rethans wrote: > The PHP development team announces the immediate availability of PHP > 7.4.0. This rele

Re: [PHP-DEV] Using PECL without installing PEAR

On Wed, Nov 13, 2019 at 5:44 PM Matthieu Napoli wrote: > Hi all, > > Following a discussion with Nikita, I understood that [installing PEAR > with PHP is deprecated]( > https://github.com/php/php-src/blob/PHP-7.4/UPGRADING#L98-L101 < > https://github.com/php/php-src/blob/PHP-7.4/UPGRADING#L98-L10

[PHP-DEV] Re: [VOTE] Union Types v2

On Fri, Oct 25, 2019 at 3:17 PM Nikita Popov wrote: > Hi internals, > > Voting on the union types RFC is now open. > > Proposal: > https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md > Voting: https://wiki.php.net/rfc/union_types_v2 > > If y

[PHP-DEV] [RFC] Add WeakMap

Hi internals, This is a follow up to the addition of WeakReference in PHP 7.4. WeakReference is an important primitive, but what people usually really need are weak maps, which can't be implemented on top of WeakReference (at least, not as exposed in PHP). This RFC proposes to add a native WeakMa

[PHP-DEV] GitHub RFC workflow

Hi internals, Now that the union types RFC is drawing to a close, I think it's time to discuss the question of RFCs in GitHub pull requests again. Overall I'm fairly pleased with how this went and would like to adopt the process in some form. In particular, I would like to start with the followin

[PHP-DEV] [VOTE] Union Types v2

Hi internals, Voting on the union types RFC is now open. Proposal: https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md Voting: https://wiki.php.net/rfc/union_types_v2 If you'd like to take a look at the discussions on this topic, those would be: Pull request: https://

Re: [PHP-DEV] Re: [RFC] Union Types v2

to new typing features (which is why, for example, we have categorically rejected a "typed arrays" implementation that has to check all array elements), but don't see union types are particular problematic in that regard, beyond what we already have. Nikita ---

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

On Mon, Oct 14, 2019 at 1:44 PM Jan Ehrhardt wrote: > Nikita Popov in php.internals (Mon, 14 Oct 2019 11:46:57 +0200): > >On Mon, Oct 14, 2019 at 11:30 AM Nikita Popov > wrote: > > > >> On Mon, Oct 14, 2019 at 11:22 AM Nikita Popov > >> wrote: > >>

[PHP-DEV] Re: [RFC] Union Types v2

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov wrote: > Hi internals, > > I'd like to start the discussion on union types again, with a new proposal: > > Pull Request: https://github.com/php/php-rfcs/pull/1 > Rendered Proposal: > https://github.com/nikic/php-rfcs/blob/u

Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions

On Mon, Oct 21, 2019 at 3:52 PM David Negrier < d.negr...@thecodingmachine.com> wrote: > Hey list, > > TL;DR: > > I'm considering writing an RFC (and a patch) to turn some warning into > exceptions in a number of PHP functions. > I would first like to gather some feedback here. > > The long versio

Re: [PHP-DEV] substr with null length

On Mon, Oct 21, 2019 at 5:03 PM Colin O'Dell wrote: > Hello Internals, > > Is there any particular reason why the substr() function doesn't accept a > null $length like mb_substr() does? It seems the behavior to read through > the end of the string can only be controlled by the presence or absen

Re: [PHP-DEV] Warning for "confusable" types

On Mon, Oct 14, 2019 at 9:21 AM Matteo Beccati wrote: > Hi Stas, > > Maybe we should just change the error message to this?> > must be an > instance of the class "resource", but resource type is > given> > OTOH, since there are actually no resource type hints, and > naming your> class "resource"

Re: [PHP-DEV] Computing code coverage on Azure Pipelines

On Mon, Sep 30, 2019 at 2:30 PM Gerard Roche wrote: > > gcov.php.net used to provide valgrind reports and code coverage for > > php-src. It no longer works with 7.4/8.0, because the OS is very old, and > > building new versions of PHP there gets very hard. The valgrind reports > > have essentiall

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

On Mon, Oct 14, 2019 at 11:30 AM Nikita Popov wrote: > On Mon, Oct 14, 2019 at 11:22 AM Nikita Popov > wrote: > >> On Sun, Oct 13, 2019 at 11:04 PM Helmut K. C. Tessarek < >> tessa...@evermeet.cx> wrote: >> >>> On 2019-10-13 17:00, Nikita Popov wrote

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

On Mon, Oct 14, 2019 at 11:22 AM Nikita Popov wrote: > On Sun, Oct 13, 2019 at 11:04 PM Helmut K. C. Tessarek < > tessa...@evermeet.cx> wrote: > >> On 2019-10-13 17:00, Nikita Popov wrote: >> > Don't know about previous versions, but at least on 7.4 setting &

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

On Sun, Oct 13, 2019 at 11:04 PM Helmut K. C. Tessarek wrote: > On 2019-10-13 17:00, Nikita Popov wrote: > > Don't know about previous versions, but at least on 7.4 setting > > OPENSSL_CFLAGS and OPENSSL_LIBS appropriately (e.g. using pkg-config > > --static --cflags/--

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

On Sun, Oct 13, 2019 at 10:51 PM Jan Ehrhardt wrote: > "Helmut K. C. Tessarek" in php.internals (Thu, 7 Feb 2019 13:39:11 > +0100): > >On 2018-12-13 17:52, Rainer Jung wrote: > >> I might be wrong, but I vaguely remember that PHp does not call > >> "pkg-config --static --libs openssl" with a corr

Re: [PHP-DEV] exit() via exception

On Fri, Oct 11, 2019 at 5:13 PM Marcio Almada wrote: > Hi! > > > > I don't believe atexit applies to os._exit(). In any case, I agree that > > > this is something we're currently missing -- we should probably add a > > > pcntl_exit() for this purpose. It should be noted though that this is > > >

Re: [PHP-DEV] exit() via exception

On Fri, Oct 11, 2019 at 3:47 PM Marcio Almada wrote: > Em sex, 11 de out de 2019 às 08:05, Nikita Popov > escreveu: > > > > Hi, > > > > Hello :) > > > Currently exit() is implemented using bailout and unclean shutdown, which > > means that we'r

[PHP-DEV] Warning for "confusable" types

Hi internals, Something I've seen play out a couple of times: Newbies try to use something like "integer" or "resource" as a type, and then get a confusing error message along the lines of "must be an instance of resource, resource given". I would like to throw a compiler warning in this case, th

[PHP-DEV] exit() via exception

Hi, Currently exit() is implemented using bailout and unclean shutdown, which means that we're going to perform a longjmp back to the top-level scope and let the memory manager clean up all the memory it knows about. Anything not allocated using ZMM is going to leak persistently. For me, one of t

[PHP-DEV] Migration tooling and the cumulative cost of purely syntactical deprecations

Hi internals, One thing that I feel gets lost when discussion is spread over multiple proposals is the following fact: Purely syntactical deprecations, such as the recently discussed case of backticks, but also the already accepted deprecations of the "alternative array access syntax" and the (re

[PHP-DEV] Re: [VOTE] Reclassifying engine warnings

On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov wrote: > Hi internals, > > I've opened the vote on //wiki.php.net/rfc/engine_warnings. > > There are 4 votes, all of them independent. The first 3 are for specific > cases that were controversial during the discussion, th

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

On Fri, Oct 4, 2019 at 5:45 PM Mark Randall wrote: > Hi Internals, > > I put forward the following RFC "Deprecate Backtick Operator (V2)" for > discussion. > > https://wiki.php.net/rfc/deprecate-backtickTrying to drag every single > discussion to the meta level is exactly what is causing these un

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

On Fri, Oct 4, 2019 at 5:45 PM Mark Randall wrote: > Hi Internals, > > I put forward the following RFC "Deprecate Backtick Operator (V2)" for > discussion. > > https://wiki.php.net/rfc/deprecate-backtick-operator-v2 > > I believe it is at least worth a discussion as to the pros and cons of > depr

[PHP-DEV] Re: [VOTE] Reclassifying engine warnings

On Thu, Sep 26, 2019 at 9:41 AM Nikita Popov wrote: > On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov wrote: > >> Hi internals, >> >> I've opened the vote on //wiki.php.net/rfc/engine_warnings. >> >> There are 4 votes, all of them independent. The fi

[PHP-DEV] fdiv() function

Hi internals, I would like to add an fdiv() function in PHP 8, implemented in https://github.com/php/php-src/pull/4769. Per https://wiki.php.net/rfc/engine_warnings the main division operation will switch to throwing DivisionByZeroError on division by zero. However, I think it is important to exp

Re: [PHP-DEV] [RFC] Union Types v2

On Tue, Sep 24, 2019 at 10:06 PM Sara Golemon wrote: > On Tue, Sep 24, 2019 at 12:24 PM Claude Pache > wrote: > > The choice of supporting precisely the two literal values `null` and > `false` > > is not arbitrary: They are the two values that are the most often used as > > sentinel values (for

[PHP-DEV] Re: [VOTE] Reclassifying engine warnings

On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov wrote: > Hi internals, > > I've opened the vote on //wiki.php.net/rfc/engine_warnings. > > There are 4 votes, all of them independent. The first 3 are for specific > cases that were controversial during the discussion, th

Re: [PHP-DEV] Shutdown Memory Allowance (aka Soft Memory Limit)

On Tue, Sep 24, 2019 at 6:42 PM Dan Ackroyd wrote: > On Tue, 24 Sep 2019 at 07:26, Peter Stalman wrote: > > > > So I would like to suggest an option for setting a shutdown memory > allowance, > > which would be the amount of additional memory allowed to be used by any > > registered error handle

Re: [PHP-DEV] PHP 7.4 BC break with openssl_random_pseudo_bytes()

On Mon, Sep 23, 2019 at 2:52 PM Christian Schneider wrote: > Hi, > I just noted (too late in the process, I know) that > openssl_random_pseudo_bytes(0) now throws an exception. > > This breaks code like > $ivsize = openssl_cipher_iv_length($method); > $iv = openssl_random_pseudo_b

Re: [PHP-DEV] Question about `global` variable declaration

either. That's because "global $var" simply imports a global variable into the local scope. You would instead write this as "global $var; $var = $someValue;". Nikita > On Sat, Sep 21, 2019 at 5:52 PM Nikita Popov wrote: > >> On Sat, Sep 21, 2019 at 11:5

Re: [PHP-DEV] Question about `global` variable declaration

On Sat, Sep 21, 2019 at 11:56 AM Kosit Supanyo wrote: > Hi Internals > > I'm working on my new proposals and I've found weirdness of global variable > declaration in zend_language_parser.y. > > global_var: > simple_variable > { $$ = zend_ast_create(ZEND_AST_GLOBAL, > zend_ast_create(Z

Re: [PHP-DEV] Should changes to EXTENSIONS be with a direct master commit?

On Fri, Sep 20, 2019 at 6:48 AM Bishop Bettini wrote: > I've got the change below staged locally, but as you can see it's direct to > master. Since that's an atypical workflow, and a first time for me, I > wanted to check before I push. > > --- BEGIN git log --- > commit f94d9dcc102ea5515974b3a72

Re: [PHP-DEV] Re: Question about merged PR #937

On Fri, Sep 20, 2019 at 12:50 AM Alexandru Pătrănescu wrote: > Hi Guilherme, > > That is what is happening when squashing commits during merge. > > I noticed this also few months ago but didn't mentioned it as I though this > is one of the usual flows. > I quickly searched it now and found it her

Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings

re, which *would* enable those optimizations. Regards, Nikita > > On Wed, Sep 18, 2019 at 12:29 PM Nikita Popov > wrote: > > > > On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov > wrote: > > > > > Hi internals, > > > > > > I've

[PHP-DEV] Re: [VOTE] Reclassifying engine warnings

On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov wrote: > Hi internals, > > I've opened the vote on //wiki.php.net/rfc/engine_warnings. > > There are 4 votes, all of them independent. The first 3 are for specific > cases that were controversial during the discussion, th

[PHP-DEV] Re: Constant propagation inside same compilation unit

On Wed, Sep 18, 2019 at 5:10 PM Benjamin Coutu wrote: > Hello, > > During performance testing of the (awesome) PHP 7.4 preloading feature I > stumbled upon a lost opportunity I'd like to point out (though this has > nothing to do with preloading per se). > > Please consider the following snippet:

[PHP-DEV] Re: [RFC] Union Types v2

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov wrote: > Hi internals, > > I'd like to start the discussion on union types again, with a new proposal: > > Pull Request: https://github.com/php/php-rfcs/pull/1 > Rendered Proposal: > https://github.com/nikic/php-rfcs/blob/u

[PHP-DEV] State of mhash?

Hi, I just noticed that the hash extension has a default-disabled --with-mhash option, that enables a couple of additional mhash_* functions. From what I was able to gather, mhash was an old extension that was superseded by hash, and hash provides a compatibility layer for mhash. Should these fun

Re: [PHP-DEV] Evolving PHP

On Fri, Sep 13, 2019 at 4:11 PM Rasmus Lerdorf wrote: > Lots of drama on internals lately. Not that different from 15-20 years ago. > A couple of things to keep in mind for everyone. > > It is not that hard to write a tool that perfectly fits your own needs and > people who are very similar to yo

[PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

Hi, Our build instructions in https://github.com/php/php-src#building-php-source-code are currently a bit bare... they show the basic "./buildconf && ./configure && make" cycle, but everyone who actually tries this will quickly find out that there is a lot more to building PHP... Every time I com

Re: [PHP-DEV] Computing code coverage on Azure Pipelines

On Sun, Sep 15, 2019 at 7:39 PM Gabriel Caruso wrote: > Hello Nikita, > > Em dom, 15 de set de 2019 às 19:29, Nikita Popov > escreveu: > >> Hi, >> >> gcov.php.net used to provide valgrind reports and code coverage for >> php-src. It no longer works with 7

[PHP-DEV] Computing code coverage on Azure Pipelines

Hi, gcov.php.net used to provide valgrind reports and code coverage for php-src. It no longer works with 7.4/8.0, because the OS is very old, and building new versions of PHP there gets very hard. The valgrind reports have essentially been subsumed by asan/ubsan on Azure Pipelines, but we're still

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

On Thu, Sep 12, 2019 at 4:11 PM Rowan Tommins wrote: > On Thu, 12 Sep 2019 at 14:55, Claude Pache wrote: > > > Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit : > > > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > > > > Marco Pivetta > > > > > > That violates blatantly DRY (twice the e

[PHP-DEV] [VOTE] Reclassifying engine warnings

Hi internals, I've opened the vote on //wiki.php.net/rfc/engine_warnings. There are 4 votes, all of them independent. The first 3 are for specific cases that were controversial during the discussion, the last one is for the remainder of the proposal. Voting closes 2019-09-26. Regards, Nikita

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

On Thu, Sep 12, 2019 at 9:40 AM Claude Pache wrote: > > Le 10 sept. 2019 à 15:31, Nikita Popov a écrit : > > > > On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov > wrote: > > > >> Hi internals, > >> > >> I think it's time to take a look a

[PHP-DEV] Re: [RFC] Reclassifying engine warnings

On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov wrote: > Hi internals, > > I think it's time to take a look at our existing warnings & notices in the > engine, and think about whether their current classification is still > appropriate. Error conditions like "undefine

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

Here are my own thoughts on how the pull request discussion for union types went... I think the main takeaway for me is that inline comments (on specific lines in the RFC) were really invaluable. Each comment thread discussed a specific issue and most of them have resulted in a direct improvement

<    3   4   5   6   7   8   9   10   11   12   >