One thought here is that updating variables_order is fine on the server, but I really don't want to force arc users to muck with php.ini.

This seems to be resolved already but just wanted to add a note - I believe Windows users currently need to modify php.ini to enable the curl extension for arcanist to work. This is from our internal documentation for installing PHP for arcanist:

Browse to C:\tools\php[some version number]. Edit php.ini as listed below.

• Note: The following modifications remove the semi-colon at the start of the line. Semi-colons are comments in .ini files and these changes are uncommenting and updating the lines.
  • Find the line ;extension=curl and remove the semicolon.
  • Locate the line ;date.timezone = and replace it with date.timezone = UTC to prevent PHP from yelling at you.

D21656 fixes variables_order.

(Or, rather, BlogSite and ShortSite both deal with 404s in a sensible way. They just don't route "/robots.txt", "/favicon.ico", or "/status/".)

This leaves some edge cases doing less-than-ideal things:

A related issue is that if you 404 on the ResourceSite, you hit a cookie exception. This isn't ideal.

We should probably route /robots.txt, but perhaps prevent it from accessing anything?

Can Piledriver be implemented as an Arcanist toolset?

I deployed this to the hosts affected by PHI2009 yesterday, and it appears to have resolved the problem.

This is actually very subtle.

I also don't see any way to really make useful assertions about this parameter statically.

PHP8 supports named arguments. At a minimum, the builtin function call_user_func_array() has changed behavior. This script:

A new linter should be introduced to detect [private final]...

I believe that covers all cases of this.

This change appears to have resolved the issue in PHI1954.

Repeatable read is required if statement based replication is used - if row replication is used - repeatable read is no longer a requirement for replication consistency...

Recently smtp-relay.gmail.com stopped accepting email from our Phabricator instance because it turns out Phabricator was sending HELO localhost.localdomain instead of HELO smtp-relay.gmail.com when doing the SMTP connection.

I'm not completely thrilled about maintaining PHP builtin webserver support...

In T13575#254280, @epriestley wrote:

I added M1, etc., to the ignored list in D21507.

I think this is now resolved. I'm not completely thrilled about maintaining PHP builtin webserver support because I think use is very limited, but since I'm currently using it I expect to support it at least until I summon the nerve to deal with Homebrew.

Guess I should probably add M1 to the remarkup blocklist now.

I switched to an M1 Mac Mini on Big Sur, which has motivated me somewhat to try to get this working since I suspect doing another install through Homebrew on M1 silicon will be more adventure than I have stomach for.

So I don't forget:

With the four revisions I've just added, arc lint works with PHP 8 when run inside the arcanist repo, and arc unit --everything has no regressions compared with PHP 7.4 (both do have a few failures but they're the same and relate to pyflakes/jshint/hg, and look environment-specific so nothing to do with PHP 8).

In D21496, declaring a method private final (which is redundant, as a private method may never be overridden) causes an issue in PHP8.

See https://discourse.phabricator-community.org/t/strpos-throwing-in-phabricatorauthpasswordengine/4335, and D21477.

For what it's worth, the only reason I was trying to figure out stuff with the built-in server was because at the time trying to get Phabricator running in Docker correctly was... not nearly as easy as I would have liked. Quickly skimming online suggests that's improved in the interim.

Yeah, it might make sense to drop it; I use it because it's easier to setup then Apache and the error log is right in my console, but setting up a real server isn't that much of a bother, except for Apple changing the rugs on you every other day (Soon with both x86 and ARM versions!)

See also T9854: Support date/time reformatting in Remarkup for a related change, although I think neither feature directly impacts the other.

This is a PCRE backtracking issue. It reproduces on an input corpus of length 3,277 bytes with only "x", " " (space), and "\n" (newline) characters, and disappears if I increase pcre.backtrack_limit.

A sometimes-suitable replacement would be some bin/request mechanism which simulates a web request in process. There are some limits to how authentic this can be, but for some substantial subset of hangs it may still be useful.

Continued in T13542.

The actual query we use to inspect table information is: