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: