XHPAST currently can't build an AST for $result = yield ..., even though this is a valid construct. This is probably a straightforward fix.

See also T13209.

See also:

See also:

PHI1667 has a couple of adjacent issues that I think aren't fully covered here.

This may partly have arisen from changes to Future behavior, not just bypass_shell changes. In particular, ExecFuture already had approximately the desired behavior, but was documented like this:

A subproblem here is that start <url> fails on Windows with bypass_shell. The likely fix is to make cmd /c start, not start, the default "browser" on Windows.

Another possibility is to do a Filesystem::binaryExists() functional test on the subprocess binary, assume the failure is "missing binary" if that test fails, and assume the failure is catastrophic otherwise.

I made some effort to find an approach here, but I think it needs to wait until Toolsets define our config/caching better. In particular, guaranteeing this naively in arc requires running a subprocess (to execute locale -a, to enumerate available locales on the system) and possibly functionally-testing hundreds of locales (or, in the general case, an arbitrarily enormous number of locales). The functional test for UTF8 behavior requires running another subprocess, to echo 🐑.

D21044 may resolve this alone, but I suspect there will be at least a little bit of followup work so I'm going to leave this open for the moment.

It's true that it has been 12 years, but I'm sure fwrite() will start returning an error code when it encounters a permanent, fatal EPIPE error condition soon.

We also have two separate pieces of ngram extraction code:

For now, I'm going to change the ngram slicing to be character-oriented. This should never be worse than the current behavior, and moves us closer to effective normalization.

This appears to be the unicode normalization chart:

If you're affected by this and arc upgrade doesn't work, the easiest fix is to run git pull in arcanist/.

Does using --max-pack-size to reduce the maximum packfile size really let Git "checkpoint" after each packfile, so the process is effectively resumable?

PHI1655 identifies a specific case where enormous packfiles may create problems:

I have some code which runs and looks plausible (i.e., not covered in piles of callback garbage), at least:

See https://discourse.phabricator-community.org/t/data-truncated-when-pushing-into-repository/3586/ for what is likely to be a related issue.

The real root cause of this issue may have been a locale setting which uses comma as a decimal separator, see T7339.

Here's an actual example of loadHardpoints($objects, $hardpoint):

In the specific case of the Hardpoints, we currently often have code which loads objects but doesn't do anything with them. For example, most Query classes use didFilterResults() to fill things-that-sure-look-like-hardpoints, but few do anything with the results.

I'm going to mark this as resolved, since:

The core idea in D5104 + D5105 is that $future->resolve() and id(new FutureIterator(array($future)))->next() (like, roughly) execute meaningfully different code paths.

Somewhere in experimental or wilds, I introduced ArcanistConduitEngine. This has some weird fake future stuff going on, so this is probably now ripe.

Couple of notes on the state of affairs here:

As of early 2020, this change works:

JIRA did this (changed how accounts are identified) again recently (key is now accountId), see T13493.

One minor issue with this is that there's some duplication when the commit Fixes Txxx and the associated revision already has the edge (which is very common if the commit Fixes Txxx, because the revision almost always also Fixes Txxx):

To follow up on this:

I can't find any changelog in any version of Git which mentions the introduction of %B. The %B behavior was introduced in this commit in March, 2010:

See also PHI1605 (internal), which provides some evidence that:

I landed everything so far to master. The new behavior in master should be:

I stumbled across what appears to be a very mild security issue in JIRA that impacts this flow. I've reported it to Atlassian's bug bounty program here (this link may or may not be visible to anyone else):

This change sequence is almost ready to remove readers and writers to accountID, but there's still a unique <accountType, accountDomain, accountID> key on the table. Removing accountID writers completely will mean that the second user to link an account of a particular type (say, an Asana account) will run into a unique key error (since they'll write a second "Asana" account with the same empty accountID as the first "Asana" account).