For prompting, the major things I want to do are:

• (T13198) Make prompts modular so there's a generic mechanism for answering them from configuration/scripting. To some degree, I expect this to be "enough rope to shoot yourself in the foot" change (i.e., it plausibly enables you to build automation on all kinds of things you probably shouldn't be building automation on) but it will also let us get rid of a fair number of flags.
• (T12996) It would be nice, although not entirely necessary, for prompts to become nonblocking.

We currently prompt with bash -c ... in most cases, and fgets(STDIN) in a subset of cases.

After the SIGINT changes in D19703, ^C no longer interrupts prompts (it is handled once the prompt exits). I think this is significantly bad. We could cascade the ^C to subprocesses.

But I'm broadly inclined to move away from the bash -c ... approach. The historical reason we do this is so that pressing the up arrow key lets you reuse lint and unit excuses, but I'd like to just remove these features.

In theory, arc unit is next on the docket so we can start getting test coverage, then Windows support. However, I suspect arc unit may unfurl into a lot of substeps.

Here are some of the bigger ideas around arc unit:

First, I plan to combine the the --json, --ugly, and --output flags into a single --format <format> flag which selects from modular formatters. We'll ship "default" and "json" formatters.

I'll possibly repurpose --output to mean --output <file>, but purely because arc unit > file is an antipattern in Bash. This may not happen immediately.

Formatters will receive results as they arrive (so they can output progress or status information) and then receive a call to render final results. The default formatter will stop rendering failures twenty pages up the scrollbuffer, and will change to balance regular feedback with making failures easily recognizable.

The --engine argument will be removed. All unit test configuration will be driven by .arcunit.

I'd like to remove or consolidate --coverage, --no-coverage, and --detailed-coverage but don't have a plan yet.

T9223 is a mess which approximately wants to be able to share an artifact between "lint" and "unit". I'm going to leave this alone for now. I think we'll probably write arc build.

I plan to let "arc land" run unit tests soon. This may introduce a concept of "phases" to unit, e.g. arc unit --phase diff vs arc unit --phase land. I'm going to let this sit for now since worst case is we need to reformat .arcunit and that's fine to do later.

Now that arc unit runs, I'm going to try to make the test suite pass so that tests are a useful tool in moving forward. We currently have 162 test failures.

Most of these are linter test failures related to changes to the WorkingCopy. Since actual linters don't care about the working copy or repository I suspect this won't be enormously difficult to resolve, although we may still be some ways away from being able to evaluate base rules and select commit ranges correctly.

The lint unit tests are significantly entangled with general lint infrastructure, so I'm now looking at making arc lint run again: I want to make sure the infrastructure is headed in the right direction overall before fixing unit tests, so we don't end up with a narrowly-scoped fix to the lint tests that needs to be rewritten once arc lint comes online. In particular, linters currently have their hands very deep in repository / working copy information. Although I think it is plausible that a linter may want access to this information (for example, we have a unit test method which reads configuration to render a link to the Phabricator install, which doesn't seem strictly bad), I think linters and unit tests should not require this information and we should not need to build an entire working copy to run a linter.

I expect to make most of the same changes to lint that I made to unit, e.g. remove support for --engine and unify outputs.

The behavior of arc lint --lintall is historically confusing: it isn't intuitive that "warning" means "show on changed lines", "error" means "show always", and "--lintall" means "--show-warnings-even-if-the-line-did-not-change". This is approximately T4287. I'd like to remove this flag and make the renderer show a hint instead:

19 warnings on lines you didn't touch were not shown. Use arc lint --severity all to show warnings on untouched lines.

I'd like to replace both --everything flags with a flag like --working-copy. Neither flag affects ignored or untracked files when run in a working copy, so --everything is misleading. This was a behavioral change from original implementation but changing the flag was too large a compatibility break at the time. A counterpoint to this is that arc lint and arc unit can currently run without a working copy (this is new in wilds and a consequence of generally better infrastructure, at least so far). It would be nice to preserve this, but then maybe the flag should be different or there should be two flags (but: yuck).

Most of the other outstanding issues with lint are not top-level issues. They may affect API decisions later on, but likely do not affect architecture decisions.

Things which are top-level are:

• better parallelization (T12996), but I expect improved data pipelines and clearer inputs and responsibilities will make this yield easily;
• a new "beautifier" phase (T8971), but I expect this to be part of arc build and broadly part of a later iteration where arc build comes into existence with beautifier/generator phases and unit/lint/land integrate with these workflows.

I want to make sure the infrastructure is headed in the right direction overall before fixing unit tests

Although I don't have it running yet, I do have a version in my working copy which seems likely to be headed in the right direction. It ends up sharing a very large amount of code with unit, and the shared code also makes good sense for the future build workflow, so this seems very promising to me.

Much of the current complexity in lint flows is around path management because lint treats paths as a key into a WorkingCopy, which is itself a sort of key into a RepositoryAPI. I think I now have a clear picture of how to simplify this, so I may be able to get arc unit passing by making smaller changes now that the big picture is somewhat clearer to me.

In retrospect, I should have rigged the hash for the the "Remove libphutil" commit to have some cool recognizable prefix like de1e7ed, since half of arcanist/ now ends up there on git blame.

One idea here: T12961 and T13012 are security issues related to the misuse of -- in argument lists. I think there was one more (less severe issue?) with Git elsewhere, too.

Some of the toolset changes are hardening arc against these cases. We could further harden arc by sometimes requiring -- separate flags and arguments:

$ arc diff HEAD^
Usage Exception: Separate flags and arguments with "--".
$ arc diff -- HEAD^
Creating diff...

We probably should not always require this since it's annoying for interactive use, but we'd ideally like to always require it for script use.

Maybe a reasonable test is actually checking if stdin is a TTY, and requiring explicit -- if not. I think this only gets us into trouble if you're doing something like arc diff --raw < diff.txt, which would become arc diff --raw -- < diff.txt. This is somewhat unintuitive, but rare, and we could also easily make arc diff --raw be arc diff --raw <path> instead.