In T11968#251717, @epriestley wrote:

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

Much of this is supported now; T13492 has some general followup.

In T13492#251814, @epriestley wrote:

XHPAST currently can not parse $x = yield $y;.

This is entangled with T9753.

XHPAST currently can not parse $x = yield $y;. I suspect this was added to the PHP grammar after XHPAST diverged. I'm hopeful the fix is straightforward.

No current plans to pursue this.

No plans to pursue this.

No longer clear what this accomplishes.

I don't currently plan to pursue this.

This is very old and we have no outstanding customer requests for ARM support.

I deployed D21062, and the three examples in the original report look good now. I checked about a dozen other pages and couldn't find anything else broken; let me know if I missed anything. Thanks for the report!

The second issue is that the API still returns a string when there is exactly one @attribute of a given type. This is a bit goofy; PhutilExecChannel is another example case.

I deployed D21061. First two example pages are good now, third one is hitting a different error. New trace is:

Docblocks may have multiple copies of the same @attribute directive, like this:

Here's the full stack trace:

One long-standing warning in a unit test cropped up (D21055) but if this does have far-reaching implications, they don't seem terribly obvious/common.

Character encoding issues aren't stable yet (see also T13500) but I think everything else here is.

The new method of installing the shell completion seems to error out for me with EXCEPTION: (Error) Call to undefined method ArcanistShellCompleteWorkflow::getPrompt() on a fresh install:

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.

The issue doesn't appear in the current code base with Firefox 73. That's not unexpected, as the UI has been tweaked several times between 2015 and now.

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/.