No plans to pursue this.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 7 2020
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.
Apr 6 2020
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.
Apr 5 2020
Apr 3 2020
XHPAST currently can't build an AST for $result = yield ..., even though this is a valid construct. This is probably a straightforward fix.
Apr 2 2020
See also T13209.
See also:
See also:
PHI1667 has a couple of adjacent issues that I think aren't fully covered here.
Apr 1 2020
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.