This is a good example of the new approach vs the old approach -- I think the new one is quite a bit cleaner and easier to deal with.

Note that we no longer need any of: a working copy; or a configuration manager; or a "testable" engine to test linters. Although some other simplifications also help permit this, switching to ArcanistWorkingCopyPath as a standalone object is the biggest enabler since linters no longer need to rely on being able to call through chains of parent objects -- like $this->getEngine()->getWorkingCopy()->getRepositoryAPI()->getFileData(...) or whatever -- to pull data.

I'm saving the stuff I'm deleting in a file, but I'd generally like to get more documentation like this into the actual documentation and not in the source code later on.

The actual documentation is now wrong, e.g. I've removed --engine.

This moved to ArcanistWorkingCopyPath.

For debugging a weird thing, I reverted this locally.

Right, I basically replaced a whole big fancy Future mechanism with "run the futures one at a time" to get this working. This likely causes a significant performance regression in arc lint, but it doesn't run yet so that's moot for now. I expect to restore futures later, but hope to find a simpler implementation. It doesn't matter for unit tests since unit tests don't run in parallel with one another (which seems like a good thing), so the performance is the same either way.

The implementation was actually doing two different things:

1. running multiple copies of the xhpast binary in parallel to improve performance;
2. sharing the generated parse trees between different linters, so if a third-party linter uses XHPAST trees it doesn't need to re-analyze files.

But the way (2) got implemented was very messy and very "make it work without changing the architecture". Once I move my focus to arc lint I expect to revisit this stuff and try to find a cleaner approach for it.

I'd ideally like (most of?) the unit tests to be able to work without having to touch disk, or even have a real file on disk at all. This change moves us some of the way toward that: we're still writing files to disk but most of (none of?) the current linters actually touch them, and we could probably stop soon or in the future without too much effort.

Today, some other tests work by building an actual git repository in tmp/ and effectively running arc inside it. Although this is the only realistic way to do some things, I think way more tests than necessary currently rely on a lot more external state than they need.

Later, I expect WorkingCopyPath to also be able to represent a real file on disk, and obviously we need to actually write to a real file when patching working copies.

I think Filesystem::getMimeType() could probably also be changed to have a "$bytes" variant, although this might be somewhat tricky. It looks like echo ... | file - works when we fall back to the file binary, and it looks like finfo_file($resource, ...) might be able to take some kind of clever PHP stream reference for the second argument and not require a write to disk.

Historically, we had (and perhaps still have?) some linters which really acted on a whole repository state. These may be trickier, but maybe they really make more sense to decompose as "build + lint" or turn into beautifiers instead of linters.

This is kind of meandering but basically: I do expect to add some code to just use the real file on disk when we have one later on, but I'm also trying to make stuff need less state/context to run.