A general issue with config is that I'd like to modularize config sources, so you can read config from a service or something if you really want, or define a custom configuration source for other Toolset commands like phage. Previously, sources were hard-coded.

T11968 was a very deep hole, but I think I've now dug my way out of it. With those changes, these workflows are now modern:

"FutureGraph" is dead. Long live "HardpointEngine".

No current plans to pursue this upstream.

Generators can't "return" until PHP 7:

PHP has a setting called post_max_size. If a POST request is larger than this size, PHP does not populate $_POST or $_FILES.

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