Summary:
Ref T13528. If we start a subprocess that immediately exits and then write to it, we can get a broken pipe error.
Recent versions of PHP appear to raise this as an actual warning, and recent changes upgrade the warning to a runtime exception.
I can't find any way to tell if the RuntimeException is a broken pipe or something else, except by examining the text of the error string.
At least for now, treat this like a "blocked pipe" condition. Since the subprocess has exited and the bytes didn't write, this should generally be reasonable.
Test Plan:
- Viewed a file in Paste with an extension that Pygments does not have a lexer for.
- This causes Pygments to exit immediately with an "unrecognized lexer" error. This closes the pipe, and the next write will fail with a broken pipe error.
- Before patch: fatal on broken pipe.
- After patch: clean resolution of the future and error condition.
Maniphest Tasks: T13528
Differential Revision: https://secure.phabricator.com/D21199
Summary:
Ref T13528. When you call `$future->resolve()`, we currently guarantee it is resolved by calling `FutureIterator->resolveAll()`.
`resolveAll()` does not actually "resolve()" futures: it guarantees that they are ready to "resolve()", but does not actually call "resolve()".
In particular, this means it does not throw exceptions.
This can lead to a case where a Future has "resolve()" called directly (e.g., via a FutureProxy), uses "FutureIterator" to resolve itself, throws an exception inside "FutureIterator", the exception is captured and attached to the Futuer, then the outer future tries to access results. This fails since it's out-of-order.
This can happen in practice with syntax highlighting futures, which may proxy pygments futures.
Instead, "resolveAll()" before testing for exaceptions.
Test Plan:
- Locally, tried to highlight a Paste with an unrecognized lexer extension using Pygments.
- Before patch: fatal when trying to access results of a Future with no results (because it has an exception instead).
- After patch: resolution throws the held exception properly.
- (See also next change.)
Maniphest Tasks: T13528
Differential Revision: https://secure.phabricator.com/D21198
Summary: Fixes T13527. Some versions of PHP strictly require that we pass a string value, and reject "stringlike" objects (objects which implement "__toString()").
Test Plan: Ran unit test, although this is somewhat aspirational because my local PHP version isn't affected.
Maniphest Tasks: T13527
Differential Revision: https://secure.phabricator.com/D21193
Summary:
See D21190. The ".gitattributes" approach fails when ".gitattributes" is in a subdirectory (or global). These are probably unusual cases, but at least one is known in the wild.
Instead:
- Restore the ":(attr:filter=lfs)" test, which seems to be the fastest accurate test available in modern Git.
- If the test fails, assume the repository is not LFS. This only impacts users running very old versions of Git.
Test Plan:
- In LFS and non-LFS repositories, created diffs. Saw correct detection again.
- Broke the command on purpose, saw LFS detection conclude "no LFS", but not fail disastrously.
Subscribers: ptarjan
Differential Revision: https://secure.phabricator.com/D21192
Summary:
See PHI1718. See also <https://discourse.phabricator-community.org/t/arc-diff-fails-due-to-git-cmd-fails/3680/>.
Currently, `arc diff` detects Git LFS with `git ls-files -z -- ':(attr:filter=lfs)'` magic. This is an accurate test, but does not work on older Git.
Try a simpler, dumber test and see if that will work. If this also has issues, we can try this stuff:
- do version detection;
- pipe the whole tree to `git check-attr`;
- try a command like `git lfs ls-files` instead, which is probably a wrapper on one of these other commands.
Test Plan:
- In a non-LFS repository, ran "arc diff" and saw the repository detect as non-LFS.
- In an LFS repository, ran "arc diff" and saw the repository detect as LFS.
Differential Revision: https://secure.phabricator.com/D21190
Summary:
Ref T13520. Replace "FileTree" with a "VectorTree" that does roughly the same thing. The major goals are:
- Compress trees which contain sequences of child directories with no sibilings.
- Build hierarchies of paths where path components may include renames.
This is approximately similar to "FileTree" and similar to client logic in the new paths panel.
Test Plan: See next change.
Maniphest Tasks: T13520
Differential Revision: https://secure.phabricator.com/D21182
Summary:
Ref T13518. The result format of this call changed in PHP 7.4, which causes us to emit "-1" matches because "-1" survives `array_filter()`.
Filter results in a way that should survive both result formats.
Test Plan: Ran `arc unit --everything` under PHP 7.4.
Maniphest Tasks: T13518
Differential Revision: https://secure.phabricator.com/D21173
Summary: Ref T13507. In Phabricator, we perform a specific "Accept-Encoding: gzip" setup test and want to manually decode the result. Allow callers to disable handling of "Content-Encoding".
Test Plan: Ran all Phabricator setup checks.
Maniphest Tasks: T13507
Differential Revision: https://secure.phabricator.com/D21121
Summary:
Ref T13507. For various messy reasons we can't blindly assume the server supports "gzip" -- but if the server tells us it does, we're on firmer ground.
If the server returns an "X-Conduit-Capabilities: gzip" header and we have compression support locally, compress subsequent requests.
This restores D21073, which was reverted by D21076.
Test Plan: With a gzip-asserting server, added debugging code and ran various "arc" commands. Saw the 2nd..Nth calls hit compression code.
Maniphest Tasks: T13507
Differential Revision: https://secure.phabricator.com/D21119
Summary:
Ref T13507. Add "Accept-Encoding: gzip" to requests if we can decompress responses.
When we receive a compressed response, decompress it.
Test Plan: Added debugging code, ran some commands, saw smaller payloads over the wire and inline decompression.
Maniphest Tasks: T13507
Differential Revision: https://secure.phabricator.com/D21118
Summary:
Ref T13507. Currently, this function is a bit conservative about what it encodes, and passing it a string of binary garbage may result in an output which is not valid UTF8.
This could be refined somewhat, since it's less than ideal if the input has valid UTF8. The ideal behavior for byte sequences where all bytes are larger than 0x7F is probably a variation of "phutil_utf8ize()" that replaces bytes with "<0xXX>" instead of the Unicode error glyph.
For now, just err on the side of mangling.
Test Plan: Dumped various binary payloads in the new gzip setup check, saw sensible output in the web UI.
Maniphest Tasks: T13507
Differential Revision: https://secure.phabricator.com/D21117
Summary: Ref T13490. This code is reachable from Phabricator binaries; only inject the legacy stuff if we're in an Arcanist stack.
Test Plan: Ran `bin/conduit help` from `phabricator/`.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21113
Summary: Ref T13490. More-or-less straightforward upgrade to modern calls.
Test Plan: Created and viewed pastes.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21104
Summary:
Ref T13490. One of the biggest issues users are hitting in modern "arc" is that workflows don't appear in "arc help" until they're updated.
Since there's still some work to do and gluing them in isn't terribly difficult, at least get things connected for now.
Test Plan: Ran "arc help", "arc help diff".
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21101
Summary: Ref T13490. These workflows don't seem worth the maintenance cost, see T13488 for discussion.
Test Plan: Grepped for methods which looked like they might only be called by these flows, only dug up the backout stuff.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21100
Summary: Ref T13490. The "RevisionRef" is currently based on "differential.query" data, but all calls other than the hash-based lookup can move to "differential.revision.search".
Test Plan: Ran revision workflows like `arc inspect` and `arc browse`.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21099
Summary: Ref T13490. I recently made "tsprintf()" more strict, but we do sometimes use "%d" and this is reasonable to support.
Test Plan: Ran "arc branch".
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21098
Summary:
Ref T13490. This is mostly straightforward.
- Drop "--show" in favor of "--as -".
- Drop support for 4+ year old "file.info" API.
- Use modern stream-to-disk support so we get a real progress bar and don't need to buffer files into memory.
Test Plan: Downloaded various files, including large files.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21097
Summary: Ref T13490. Moves "arc amend" to Toolsets with modern ref/hardpoint code.
Test Plan: Ran "arc amend --show", "--revision", etc. Hit all the prompts and errors, probably?
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21095
Summary:
Ref T13490. I'm continuing to move toward modernizing "amend", which needs to load some objects by symbol at top level.
Add an API to support this.
Test Plan: Added an API caller to "arc inspect", ran it and hit the new code. Things seemed to work.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21094
Summary: Ref T13490. Make terminal strings work more like HTML does in Phabricator, and make it easier to display refs.
Test Plan: Added some display code, ran `arc inspect` to hit it, saw a nice ref printed.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21093
Summary:
Ref T13490. I'm attempting to update "arc amend", but it needs to fetch revision authors to raise an "amending a revision you don't own" error.
Support user-symbol resolution.
Along the way, this introduces some infrastructure for abstracting away iteration over a multi-page Conduit result set.
Test Plan:
- Ran "arc inspect ..." for various "user(...)" queries.
- Set page size to 3 and issued a general query, saw the future page it away properly.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21092
Summary:
Ref T13490.
- Support resolution of revision symbols into revision objects.
- Align commit inspection better against commit symbols.
- Make "arc inspect --explore" recursively load all object hardpoints.
- Add a "commit message" hardpoint to "RevisionRef".
Test Plan: Used "arc inspect" to resolve commits and revisions. Used "--explore" to see the whole tree.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21091
Summary:
Ref T13490. Frequently, we know the symbolic name of a commit (like "master") but need the immutable identifier for it (the commit hash).
Provide a Ref and Query for doing this lookup.
Test Plan: Ran `arc inspect symbol(...)` with various symbols, saw appropriate resolutions, nulls, or errors.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21090
Summary:
Ref T13490. "ExecFuture" can raise a "CommandException" when the subprocess fails. In most cases, this is desirable, since we usually do not expect subprocesses to fail.
Currently, "execx()" (which raises these exceptions) is the synchronous default (with the more verbose "exec_manual()" as an alternative if you expect the command may return an error code), but the Future variation has no way to hint that external resolution should raise an exception if the process exits with an error.
Since the "HardpointEngine" yield construct can resolve external futures, add a mode for this to simplify implementing "HardpointQuery" classes a bit. Without this, they either need to retain "$futures" and manually call "resolvex()", or check the "$err" result and throw some other exception, both of which are low-value boilerplate (queries that want to do this still can, of course).
This is basically like providing a hint that the futures should be resolved with "resolvex()" instead of "resolve()".
Also, make this the default behavior of a new "$api->newFuture()" wrapper.
Test Plan: Intentionally broke a command in a HardpointQuery, got a sensible exception automatically during external future resolution.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21089
Summary: Ref T13490. There's more `array(...)` happening in this API than necessary. Sugar it slightly.
Test Plan: Grepped for "loadHardpoints()", ran a couple workflows.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21088
Summary: Ref T13490. A few older "defineHardpoint()" calls are sticking around. They no longer have callers; get rid of them.
Test Plan: Grepped for this symbol, no hits.
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21087
Summary:
Ref T13490. These workflows are aliases of one another, which is a little silly, but currently all identify as "arc feature" in "arc help".
Straighten that out, at least.
Test Plan: Ran "arc help", "arc branch".
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21086
Summary:
Ref T13490. Bring "arc prompts" from "wilds" and hook it into the prompt in "arc shell-complete".
See D21069. Fix an issue where the shell hook tested for a path other than the path it writes to.
Test Plan: Ran "arc shell-complete" with no hook and got a prompt. Shell completed things. Ran "arc prompts shell-complete".
Maniphest Tasks: T13490
Differential Revision: https://secure.phabricator.com/D21085
Summary: Ref T11968. "RefQuery" is now "HardpointEngine". "HardpointLoader" is now "HardpointQuery".
Test Plan: Grepped for affected symbols.
Maniphest Tasks: T11968
Differential Revision: https://secure.phabricator.com/D21083
Summary:
Ref T11968. "arc browse", "arc branch", and "arc diff" currently may execute into the RefQuery engine. Reroute them to the HardpointEngine.
This removes older-generation "Ref" objects and renames the replacement "RefPro" objects to "Ref".
Test Plan: Ran "arc branch", "arc browse <various things>", "arc diff", searched for affected symbols.
Maniphest Tasks: T11968
Differential Revision: https://secure.phabricator.com/D21082
Summary: Ref T11968. Merge the modern hardpoint queries and refs for the "browse" workflow as "pro" variations.
Test Plan: Ran `arc inspect browse(...)` for objects, paths, commits, and revisions.
Maniphest Tasks: T11968
Differential Revision: https://secure.phabricator.com/D21080
Summary:
Ref T11968. Continue bringing modern yield-based hardpoint code into "master" in the parallel "Pro" classtree.
Adds "working-copy(commit-hash)" as an inspectable ref.
Test Plan: Inspected working copy refs, saw them resolve revisions by commit hash and commit message.
Maniphest Tasks: T11968
Differential Revision: https://secure.phabricator.com/D21079
Summary:
Ref T11968. Inches toward the new ref/hardpoint code by introducing the modern refs as "RefPro" objects and supporting an "arc inspect <object>" to load objects and hardpoints.
This doesn't impact any existing runtime behavior.
Test Plan: Ran "arc inspect [--all] commit(...)", got hardpoint queries and yield-based data fetching.
Maniphest Tasks: T11968
Differential Revision: https://secure.phabricator.com/D21078
Summary:
Depends on D21074. Ref T13490. Ref T11968. Before toolsets, Arcanist has a "WorkingCopyIdentity" object. After toolsets, it has a "WorkingCopy" object.
Most workflows don't access either one, so make a slightly-breaking API change to simplify the transition.
- "getWorkingCopy()" now returns a modern object (a "WorkingCopy").
- "getWorkingCopyIdentity()" now returns an older object (a "WorkingCopyIdentity").
This isn't backward-compatible, but out-of-date code should get an explicit failure with clear resolution steps.
Test Plan: Ran "arc lint", "arc branch", and a few other commands. Grepped for "getWorkingCopy()".
Maniphest Tasks: T13490, T11968
Differential Revision: https://secure.phabricator.com/D21075
Summary:
Ref T11968. Ref T13490. These are the workflows which currently use the intermediate-level hardpoint code (which made hardpoints formal, but didn't do the yield stuff).
Move toward updating them by doing some basic bookkeeping, with a few compatibility adjustments to the parent Workflow class.
Test Plan: Ran "arc branch" and "arc browse" with various arguments.
Maniphest Tasks: T13490, T11968
Differential Revision: https://secure.phabricator.com/D21074
Summary:
This reverts commit 7e25288f49. See T13507 for discussion, shortly.
This needs to be switched to capability detection because some server configurations can not actually accept these requests.
Test Plan: Straight revert.
Differential Revision: https://secure.phabricator.com/D21076
Summary: Ref T13507. Enable compression in the body of Conduit requests if we have client support for it; we expect the server should always support it.
Test Plan: Created this revision, ran random "arc" commands that use Conduit. Added debugging code, saw payload size drop.
Maniphest Tasks: T13507
Differential Revision: https://secure.phabricator.com/D21073
Summary:
Depends on D21071. Ref T11968. Currently, "ConduitEngine" tries to lightly parallelize futures. This was a compromise when the initial "hardpoint" change didn't plan to pursue real request paralleization.
Now that the newer hardpoint change does, we don't need onboard resolution in ConduitEngine. Throw it away.
When the engine is supposed to resolve a future, it now just resolves that future on its own. This should be functionally identical to the previous behavior, except that it may be slower.
(In practice, because HTTP futures are backed by an internal cURL request pool, this proably has little effect anywhere. Moving to modern hardpoints will make performance no worse than it was prior to this change, in any case.)
Test Plan: Ran various modern "arc" commands.
Maniphest Tasks: T11968
Differential Revision: https://secure.phabricator.com/D21072
Summary:
Depends on D21070. Ref T11968. Adds "yield"-aware query classes for parallelizing service calls.
These will replace the similar (but not yield-aware) "Hardpoint" classes introduced previously. This is an API change but most of the old classes still exist and still do the same thing, just with more "yield" statements.
This just adds a bunch of new code with no callers and no API updates.
Test Plan: See future changes.
Maniphest Tasks: T11968
Differential Revision: https://secure.phabricator.com/D21071
Summary:
Ref T11968.
- Allow "WorkingCopy" objects to maintain an API object and update callers ("get...()" instead of "new...()").
- Always generate a WorkingCopy object and a RepositoryAPI object.
Currently, code has to look like this:
```
$working_copy = ...
if ($working_copy) {
$repository_api = ...
if ($repository_api [instanceof ... ]) {
```
This is clunky. There's also no reason some "arc" commands can't run outside a VCS working directory without special-casing how they interact with the filesystem.
Conceptually, model the filesystem as a trivial VCS (which stores exactly one commit, always amends onto it, and discards history). Provide a trivial WorkingCopy and API for it.
(This change isn't terribly interesting on its own, but chips away at landing the new Hardpoint infrastructure.)
Test Plan: Ran `arc version`, `arc upgrade`.
Maniphest Tasks: T11968
Differential Revision: https://secure.phabricator.com/D21070
Summary:
Depends on D21067. Ref T13492. Converting unit tests to be readable exposed this error in the grammar.
Normally, "grammar_rule" rules emit a standalone Node. In this case, the bottom-level grammar rule is a collection of trivial rules and the callers configure the Node. Wrap the bottom-level rule in a configuration rule so the node is configured correctly and consistently, in exactly one place.
Test Plan: Ran unit tests.
Maniphest Tasks: T13492
Differential Revision: https://secure.phabricator.com/D21068
Summary:
Depends on D21066. Ref T13492. The switch of unit test data to stable/readable output exposed this bug in parsing of variadic calls: some nodes are not given types properly.
Fix the parser and update the test.
Test Plan: Ran the test, which now works.
Maniphest Tasks: T13492
Differential Revision: https://secure.phabricator.com/D21067
Summary:
Depends on D21065. Ref T13492. Swap existing "expect" blocks from unstable, unreadable JSON to readable, stable trees.
(There are two "INVALID TYPE" outputs which this update effectively detects and which future changes correct.)
Test Plan: Ran "arc unit --everything", got a clean build.
Maniphest Tasks: T13492
Differential Revision: https://secure.phabricator.com/D21066
Summary:
Depends on D21064. Ref T13492. Earlier, see D17819. This is essentially the same change, although I inlined the token stream into the node list.
This intentionally breaks most tests since it just has the new "expect" generator; the next change will fix them by swapping the test bodies.
Test Plan: Ran "arc unit --everything" after the next change (which fixes all the tests), got a clean build. This change on its own fails all existing XHPAST tests since the block formats don't match.
Maniphest Tasks: T13492
Differential Revision: https://secure.phabricator.com/D21065
Summary:
Depends on D21063. Ref T13492. Currently, XHPAST defines a version in both PHP code and C code, and they must be kept in sync.
Switch to a single definition in PHP, then carry it through the build pipeline into C.
Test Plan: Did a clean rebuild of XHPAST, saw a version number carried in from PHP. Ran "xhpast --version".
Maniphest Tasks: T13492
Differential Revision: https://secure.phabricator.com/D21064
Summary:
Fixes T9753. Changes some time ago (in D13970 + D13974) improved XHPAST build compile-time warning behavior under Bison 3.
However, macOS still ships with Bison 2.3 and these changes prevent XHPAST from building with Bison 2.3. The changes didn't introduce version detection, so Bison 2.3 builds fail somewhat mysteriously without obvious next steps.
It's relatively easy to install Bison 3 on macOS via Homebrew, but the Bison 3 changes aren't terribly substantive and XHPAST doesn't actually depend on any Bison 3 features, so just return to Bison 2.3 for now.
It would be reasonable to undo this again and retarget Bison 3 in the future, but ideally we should wait until macOS ships with Bison 3 or we have a specific reason to bump the minimum required version to 3. If/when we do, we should version-detect Bison and raise a clear error message.
Test Plan: Built xhpast under Bison 2.3 on a default macOS install using "make cleanall && make install".
Maniphest Tasks: T9753
Differential Revision: https://secure.phabricator.com/D21063
