We currently have no interest in this from customers, so I don't plan to pursue it. If customer interest arises, there's a plausible pathway forward.

I have another patch on top of D20998 which brings unit over, but it's currently so broken that it can't diff itself.

I'm also going to collapse as much of experimental into master as I can here, make the minimum required PHP version 5.5 (see T11968), and attempt to collapse wilds.

See also https://discourse.phabricator-community.org/t/storage-upgrade-failed-class-phutilauthadapter-not-defined/3468.

Oh, no, that's unrelated:

Looking at this in slightly more detail, I think the immediate issue is just that .gitignore specifies /src/extensions/*, not /src/extensions/**.

I actually tried to use the extensions directory to hide Composer's vendored files and ran into this same issue.

The operation in PHI1329 (against a ~8GB export) went through cleanly. Remaining work here is:

This is something of an aside, but it would be nice to formalize PhutilConsoleProgressBar into a generic progress sink. A lot of bin/storage dump-related stuff could use this and bin/host download could obviously use it, and we likely have some use cases for reporting progress to the web via the API, but PhutilConsoleProgressBar lacks an indirection layer to really make this work cleanly.

My tentative plan is to add methods for sending the output to disk to HTTPSFuture, then go down the new parser pathway only if we're writing to disk. This should limit the amount of surface area exposed on the new parser.

A possible issue is that letting cURL pick a protocol might lead to it selecting HTTP/1.0 in some cases (how/when could it possibly do this?

According to curl/symbols-in-versions (this is a text file in the repository):

A possible issue is that letting cURL pick a protocol might lead to it selecting HTTP/1.0 in some cases (how/when could it possibly do this? Only by hard-coding known-broken hostnames, I think?), and forcing it to use HTTP/1.1 could break those cases, so maybe I'll go spelunking here. I also can't immediately find a date of introduction for CURL_HTTP_VERSION_1_1 from the documentation.

I believe this is essentially just T13209.

D19637 doesn't actually improve this, but it brings us a step closer (since the logic is now in PHP and can be modified more easily to label symbols and add context).

See T13098. I currently plan to expose the shell-complete workflow to every arc toolset, but I don't think being able to shell-complete bin/storage upgrade or similar is worth pursuing.

Not a problem - thanks for fixing that so quickly.
I can confirm that fixed the issue for us.

(I'll fix this if you don't get there first, but have used up all my brain energy for today. And thanks for the report!)

Would it be acceptable to change PhutilRemarkupHyperlinkRule to catch this exception and behave as if it were a non-whitelisted protocol? (Happy to draft the patch, just want to check before I do so)

This change creates a slight problem for us at KDE as we have some historical commits in our Subversion repository which have URLs in them which are invalid. This exception means that:

• Herald spins forever trying to process these commits, failing every single time (currently up to 855 failures).
• The commit can't be viewed in the browser (See https://phabricator.kde.org/R883:271607)

We haven't seen other users encounter this issue in several years.

No current plans to ever pursue this.

Aha! That works wonderfully. I think this is INVALID, then.

Use tsprintf() ("terminal string print formatted") instead of phutil_console_format():

We're happy to take a patch, too!

In T8845#214252, @SvHu wrote:

It's pretty big deal for us because we are using phriction to collect helpdesk FAQ. We have modified TOC to be displayed in the beginning of the page and would like to use ponder are storing questions. Atm using ponder links in phriction as headings also shows toc values as X.

I think this is, to at least some degree, a legitimate security problem. Consider:

Yes, it is not "incorrect" but it is not human-readable format problem same with T8973 either. Chinese / Japanese / Korean unicode should be shown as what it is instead of some unreadable unicode digitals, especially in TRANSLATION functions, otherwise how to translate and confirm that?

This behavior is not "incorrect", it just isn't the most human-readable format we could use. I'm going to merge this into T8973, which discusses this and other potential improvements to human-readability for JSON encoded for presentation.