wilds and experimental have mostly collapsed together into master, and this is survived by T13488.

These are in better shape now:

I think I'm going to remove these workflows outright:

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.

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.