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!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 6 2020
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
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:
Apr 4 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.
This is breaking commit breaks drydock: PHP Fatal error: Cannot override final method Future::getResult() in /core/data/drydock/workingcopy-75/repo/phabricator/src/applications/harbormaster/future/HarbormasterExecFuture.php on line 50
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.