1
0
Fork 0
mirror of https://we.phorge.it/source/arcanist.git synced 2024-09-20 00:49:11 +02:00
Commit graph

2362 commits

Author SHA1 Message Date
epriestley
a77cfb023d When a proxy future wraps a future which throws an exception, resolve with an exception
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
2020-05-01 09:12:22 -07:00
epriestley
696ec3f975 Work around "mb_check_encoding(<stringlike-object>)" warning in particular versions of PHP
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
2020-04-30 07:19:45 -07:00
epriestley
284139a24e Restore the ":(attr:filter=lfs)" test for LFS
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
2020-04-29 21:04:44 -07:00
epriestley
ade9b51a1f Detect LFS by looking for tracks in ".gitattributes" instead of using "ls-tree"
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
2020-04-29 16:23:44 -07:00
epriestley
6ec09b2f48 Replace "PhutilFileTree" with a more abstract "VectorTree"
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
2020-04-28 12:09:56 -07:00
epriestley
b81818b287 Accommodate PHP 7.4 changes to certain "preg_match_all()" calls
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
2020-04-26 08:40:08 -07:00
epriestley
bf76fa547d Make "arc <workflow> --help" work again for workflows which haven't updated yet
Summary:
See <https://discourse.phabricator-community.org/t/help-is-no-longer-present-for-arc-subcommands-in-todays-stable/3786>.

The "--help" flag ends up falling through to the old "arcanist.php", where it becomes lost. Catch it earlier so "arc diff --help" prints diff help, for instance.

Test Plan: Ran `arc help diff`, `arc diff --help`, `arc --help diff`, and similar commands for updated workflows; got help.

Differential Revision: https://secure.phabricator.com/D21168
2020-04-25 08:57:28 -07:00
epriestley
68f050bd14 Allow HTTPFuture callers to disable processing of "Content-Encoding" response headers
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
2020-04-15 06:28:25 -07:00
epriestley
377ed2ed8d If the Conduit server asserts it has the "gzip" capability, compress requests
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
2020-04-14 16:50:54 -07:00
epriestley
a77da426af If the Conduit client supports gzip, make calls with "Accept-Encoding: gzip"
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
2020-04-14 16:23:53 -07:00
epriestley
890b57de1e In "phutil_loggable_string()", encode every byte above 0x7F
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
2020-04-14 16:03:12 -07:00
epriestley
9d0100bda7 Only inject legacy Arcanist workflows into "help" if run from the context of an Arcanist runtime
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
2020-04-14 13:24:00 -07:00
epriestley
d408a80ae1 Update "arc paste" for Toolsets
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
2020-04-13 15:01:51 -07:00
epriestley
c8dd2a3753 Crudely bridge legacy workflows into "arc help"
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
2020-04-13 11:41:05 -07:00
epriestley
196f8f54ce Remove "backout", "close", "flag", "start", "stop", "time", and "revert" workflows
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
2020-04-13 07:09:49 -07:00
epriestley
4719341c27 Upgrade (most) Differential API callsites to "differential.revision.search"
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
2020-04-13 06:42:25 -07:00
epriestley
ab589ab31d Restore "%d" support to "tsprintf()"
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
2020-04-13 04:35:59 -07:00
epriestley
21e80a635d Upgrade "arc download" to Toolsets
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
2020-04-12 16:18:03 -07:00
epriestley
076f7be484 Update "arc call-conduit" for Toolsets
Summary: Ref T13490. Fairly straightforward update.

Test Plan: Made various Conduit calls.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21096
2020-04-12 16:17:47 -07:00
epriestley
0f2e277cd9 Update "arc amend" for Toolsets
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
2020-04-12 13:48:26 -07:00
epriestley
ff4c1e7c81 Add a "SymbolEngine" to support top-level ref resolution by symbol
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
2020-04-12 13:48:09 -07:00
epriestley
5fc50c226a Add some support code for printing refs to stdout
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
2020-04-12 13:44:46 -07:00
epriestley
088b157444 Add ref lookup for username symbols
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
2020-04-12 13:42:51 -07:00
epriestley
1f18f25fa5 Add a "RevisionSymbolRef", revision commit messages, and make "--explore" recursive
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
2020-04-12 13:24:32 -07:00
epriestley
4cc05c377d Add a "CommitSymbolRef" for resolving symbolic commits into stable commit hashes
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
2020-04-12 13:19:53 -07:00
epriestley
92be6df0eb Add a mode to "ExecFuture" that makes "resolvex()" semantics the default
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
2020-04-12 13:18:11 -07:00
epriestley
73f48aca74 Allow "loadHardpoints()" to accept a single ref and/or a single hardpoint
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
2020-04-12 13:17:41 -07:00
epriestley
6e24e10bdb Remove obsolete definitions of "defineHardpoints()" in older Ref objects
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
2020-04-12 13:16:22 -07:00
epriestley
9a198ffcc5 Update "feature", "branch", and "bookmark" flows to report properly in "arc help"
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
2020-04-12 13:16:07 -07:00
epriestley
ccd1ebb256 Port "arc prompts" from wilds and fix a path issue in shell completion
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
2020-04-11 10:43:05 -07:00
epriestley
387027eb3a Restore "arc alias" shell aliases
Summary:
See <https://discourse.phabricator-community.org/t/exception-when-trying-to-run-an-arc-alias-undefined-method-arcanistalias-getshellcommand/3731/>.

Shell aliases got lost in the shuffle of porting "arc alias"; restore them.

Test Plan: Bound `arc ls` to `ls -alh`, ran `arc ls`.

Differential Revision: https://secure.phabricator.com/D21084
2020-04-11 09:59:48 -07:00
epriestley
fff2fc8bc9 Remove "RefQuery" and all "HardpointLoader" code
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
2020-04-11 06:46:53 -07:00
epriestley
dc42f51cf7 Reroute all RefQuery callers to HardpointEngine
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
2020-04-11 06:46:23 -07:00
epriestley
9e72e4ed1d Bring "pro" browse queries from modern hardpoint code
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
2020-04-10 08:05:24 -07:00
epriestley
8bb81217d5 Bring a "pro" WorkingCopyState ref to "master"
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
2020-04-10 06:16:37 -07:00
epriestley
adea2550f5 Introduce "arc inspect" and some of the new ref/hardpoint classes
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
2020-04-10 05:01:25 -07:00
epriestley
92b29f53f3 Rename "getWorkingCopy()" to "getWorkingCopyIdentity()" in Arcanist
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
2020-04-10 04:24:29 -07:00
epriestley
391c164313 Trivially update "arc branch/feature" and "arc browse" for Toolsets
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
2020-04-10 04:23:03 -07:00
epriestley
f56c6bde2b Revert "Compress requests from the Conduit client to Phabricator"
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
2020-04-09 12:25:18 -07:00
epriestley
7e25288f49 Compress requests from the Conduit client to Phabricator
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
2020-04-08 09:24:54 -07:00
epriestley
deb72c37db Remove onboard future bulk-resolution from ConduitEngine
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
2020-04-08 09:24:37 -07:00
epriestley
85141c4d90 Add new "Hardpoint" classes to support request parallelization
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
2020-04-08 09:23:50 -07:00
epriestley
0b3cd39230 Update the "WorkingCopy" API and create a fallback "Filesystem" working copy
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
2020-04-08 09:22:43 -07:00
epriestley
a1ee2ab931 Fix improper XHPAST parsing of namespace grammar like "use x as private;"
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
2020-04-07 14:35:42 -07:00
epriestley
e03431def8 Fix XHPAST parsing of variadic calls
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
2020-04-07 14:33:37 -07:00
epriestley
a689dee228 Update XHPAST "expect" test blocks to the new stable, human-readable format
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
2020-04-07 14:32:48 -07:00
epriestley
8a7ce97b51 Make XHPAST unit test "expect" blocks stable and human-readable
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
2020-04-07 14:31:56 -07:00
epriestley
6d15c6ea48 Remove duplication of XHPAST version in PHP and C code
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
2020-04-07 14:31:11 -07:00
epriestley
763ac445dc Revert xhpast changes that impacted builds under Bison 2.3
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
2020-04-07 14:29:19 -07:00
epriestley
33dc2fe819 Allow "phage" to print execution status on SIGINT
Summary: Ref T13490. The new Arcanist runtime supports workflow signal handling, but Phage isn't quite able to make use of it. Clean up the last few pieces so it can work.

Test Plan: Ran "phage", hit ^C, got status information.

Maniphest Tasks: T13490

Differential Revision: https://secure.phabricator.com/D21060
2020-04-06 11:09:43 -07:00