Summary: This should be done for all external and configurable linters.
Test Plan: Linted file with lint problems, changed options, relinted.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4475
Summary:
If linter with file cache granularity stops linting then we don't run it on the same path next time.
But we still run linters with non-file cache granularity causing that they run even on the paths that would be stopped otherwise.
Test Plan:
Put global granularity linter after Generated linter.
Caused an error from this linter but in ignored path.
Verified that 'stopped' is saved in `lint-cache.json`.
Linted the same files second time, verified that the path is still skipped (wasn't before).
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4446
Summary: To have at least one real callsite.
Test Plan:
$message = new ArcanistLintMessage();
$message->setOtherLocations(array());
$message->setOtherLocations(array(array()));
$message->setOtherLocations(array(1));
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4419
Test Plan: Created function named `f_a`, manually set other location.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4412
Summary:
Some errors (duplicate declaration, invalid number of arguments) have more related places.
We need to notify user if he changes any related place.
This could be currently achieved by triggering errors instead of warnings or by including both files in the range (impossible if the locations are in different files) or by issuing multiple errors.
All options are too aggressive.
Test Plan: Issued error on unmodified line with other location on modified line.
Reviewers: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4392
Summary:
FB runs some linters on background and it's a magnificent hack using `ParallelLinter` (two instances), `BackgroundLinter` and `FutureLinter`.
I want to simplify this by resolving the futures in engine instead of in some virtual linter.
It also seems like a better place to do it.
It should also fix caching problems I have with them (because the virtual linters don't know about the cache at all).
Test Plan: None yet.
Reviewers: epriestley, nh
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4380
Summary:
Fixes T2175. Git generates patches which have "\n" line endings on every system. We currently generate patches with system-dependent line endings.
Git accepts system-dependent line endings in almost call cases, but part of the parser tests for "\n" explicitly. T2175 has an example of this.
Test Plan:
Ran `arc export --git --revision D4366 > export.git` on a Windows machine, verified "\n" line endings. Ran the same with `--unified`, verified "\r\n" line endings.
(I didn't add any unit tests for this because it's Windows-dependent and very difficult to test meaningfully right now -- i.e., test that appliable patches are generated -- since the git reconstitution test doesn't run on Windows either, because we can't yet untar things there.)
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2175
Differential Revision: https://secure.phabricator.com/D4373
Summary: If you dump `arcanist/` into "Program Files" or similar, the `.bat` currently breaks. Quote the path so it doesn't. Fixes T1436.
Test Plan: Ran `arc` with `arcanist/` in a path with spaces in it.
Reviewers: vrana, btrahan
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1436
Differential Revision: https://secure.phabricator.com/D4375
Summary:
D4186 added an "svn status --xml x y" form to getSVNStatus(), but the parser doesn't work for multiple files, since we get multiple <target /> elements in the XML output. So, curently, `arc diff` works (one target, all files) and `arc diff x` works (one target, x) but `arc diff x y` does not (more than one target, hits the exception).
$ arc diff QUACK2 QUACK3
Exception
Expected exactly one XML status target.
Test Plan: Ran `arc diff QUACK2 QUACK3` in a working copy with modified QUACK2, QUACK3. Ran `arc diff`; `arc diff QUACK2`.
Reviewers: vrana, btrahan, codeblock, JThramer
Reviewed By: codeblock
CC: aran
Differential Revision: https://secure.phabricator.com/D4372
Summary: Ref T2296. This error is unreachable right now -- when I fixed all the "\r\n" stuff, we always end up with a nonempty first line for an empty input. Do this test earlier and more explicitly. This results in a less useful error: "expected (some junk) on line 1" instead of "can't parse an empty diff".
Test Plan: Tried to parse an empty diff, got a "you can't parse an empty diff" error.
Reviewers: btrahan, vrana, codeblock
Reviewed By: codeblock
CC: aran
Maniphest Tasks: T2296
Differential Revision: https://secure.phabricator.com/D4370
Summary: Add a comma because it was going to annoy the crap out of me.
Test Plan: See the comma. :)
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4365
Summary: We want to use TYPE_DIFF_DIDBUILDMESSAGE to abort arc diff when a message doesn't fit some
Test Plan: Created an EventListener subscribed to TYPE_DIFF_DIDBUILDMESSAGE, validated the 'message' field was filled in
Reviewers: vrana, epriestley
Reviewed By: epriestley
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D4361
Summary: This fix lets you run arc lint from any directory in the repository
Test Plan: Ran arc lint from any directory
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4356
Summary:
Currently, this spawns 125 concurrent processes on my machine, which overflows some limit and gives me an error:
PHP Warning: proc_open(): unable to create pipe Too many open files in /INSECURE/devtools/libphutil/src/future/exec/ExecFuture.php on line 491
Instead, limit parallelism to 16. The runtime is approximately the same for me, and dominated by other concerns (conduit calls).
Test Plan: Ran `arc branch` successfully. Ran `arc branch --trace`, observed behavior.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D4336
Summary:
Lints cpp code using the cppcheck static linter. This linter needs to
be downloaded and built from http://cppcheck.sourceforge.net/
Test Plan: Used it on a few files.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4353
Summary: Adds arc lint support for cpp files with Google's cpplint.py lint checking.
Test Plan: ran it on some cpp files. Added unit tests
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4344
Summary: see title
Test Plan: ran arc install-certificate <uri> in a directory without an .arcconfig and it worked! ran arc install-certificate in a directory with an .arcconfig and it worked! ran arc install-certificate <uri> in a directory with an .arcconfig and noted it correctly overrode the .arcconfig
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2251
Differential Revision: https://secure.phabricator.com/D4332
Summary:
I type "arc brnach" about 300 times per day.
- Allow arc commands to be specified by unique prefix ("exp" for "export", "lib" for "liberate").
- Allow arc commands to be specified by unique levenshtein edit distance <= 2 ("brnach" for "branch", "halp" for "help", "ptach" for "patch").
- Reorganize code out of "arcanist.php".
I think this will be uncontentious because arc commands are rarely destructive, but if people complain we can either require certain commands be typed exactly (maybe "land"?) or allow this feature to be disabled in configuration.
Test Plan:
$ arc br
Usage Exception: Unknown command 'br'. Try 'arc help'.
Did you mean:
branch
browse
$ arc brnachh
Usage Exception: Unknown command 'brnachh'. Try 'arc help'.
$ arc brnach
(Assuming 'brnach' is the British spelling of 'branch'.)
doc-security No Revision security
sms Needs Revision D319: Add SMS support to Phabricator
phxtag No Revision derp
arantag No Revision derp
...
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D4305
Summary: flake8 is the better maintained combination of pep8 and pyflakes
Test Plan: There's a test!
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin, jack
Differential Revision: https://secure.phabricator.com/D4082
Summary:
Fixes T2138.
- When a pull fails, restore the original branch.
- When a push fails, complain about it really loudly.
NOTE: No test plan for push yet since I'm not sure this is the right remedy, see T2138 for discsusion.
Test Plan:
- Tested pull by changing "git pull" to "git xxpull" and running "arc land". Saw the pull fail and my original branch restored.
Reviewers: vrana, aran
Reviewed By: vrana
Maniphest Tasks: T2138
Differential Revision: https://secure.phabricator.com/D4265
Summary: If you are explicit then there is no need to ask you.
Test Plan:
$ touch a
$ arc diff
$ arc diff a
$ arc diff existing
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4186
Summary:
Recently, in D4097 or one of the precursors I refactored this. However, when $rev is null parseBaseCommitArgument() throws ("This VCS does not support commit ranges."). Shield the call so it only happens if if $rev is nonempty (we still want to make the call, so "arc lint --rev x" on SVN will throw and inform the user that "--rev" is incorrect usage).
(@vrana, this was reported by FB and might be worth pushing.)
Test Plan: Ran "arc diff --preview <path>". Grepped for other parseBaseCommitArgument() callsites and verified they don't have similar issues.
Reviewers: vrana, btrahan, chad
Reviewed By: chad
CC: aran
Differential Revision: https://secure.phabricator.com/D4241
Summary: I don't know how to not be strict here plus we (Arcanist developers) don't have access to user's error log.
Test Plan:
Undeclared `ArcanistDiffWorkflow::$console`, then:
$ arc diff
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D3607
Summary:
The main added value is loading the branch name from revision.
Sometimes I know the revision ID but I don't know the branch name.
The missing piece is the starting point of the branch.
I was thinking about using `arc.land.onto.default` but we also need to get 'origin'.
This is also the last step of a simple workflow where underlying VCS is not abstracted away.
In future, we can implement this for other APIs.
Test Plan:
$ arc branch new_branch
$ arc branch new_branch
$ arc branch D4168
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4170
Summary:
Currently, if you run `arc` in arcanist/ or libphutil/ and your PATH and on-disk configuration are set up so a different version of arc or libphutil are the ones that actually load, we fail with an exception like "running arcanist in a different copy of arcanist is not supported".
This causes problems for Harbormaster, since we'd like to be able to run 'arc' in a copy of libphutil/ and have it execute unit tests for that copy rather than failing abruptly. So, if we detect that we're in arcanist/ or libphutil/, execute 'arc' again with the same arguments but force it to load the working copy in place of either the 'arcanist/' or the 'libphutil/' that it decided to load.
This is pretty much horrible black magic.
Test Plan: Ran 'arc list --trace' inside copies of libphutil/ and arcanist/ outside of the normal include chain. Saw it detect these, emit a message, and re-execute itself correctly.
Reviewers: btrahan, vrana
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1049
Differential Revision: https://secure.phabricator.com/D4225
Summary: After D4191 this is a fatal.
Test Plan: Created this revision.
Reviewers: vrana, btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D4219
Summary: Adds "arc unit --everything", which runs every available test, provided the test engine supports it. Also add JSON output.
Test Plan: Ran `arc unit --everything` in arcanist/, libphutil/ and phabricator/. Saw all tests run.
Reviewers: btrahan, vrana
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2065
Differential Revision: https://secure.phabricator.com/D4214
Summary:
See D4049, D4096.
- Move commit range storage from Mercurial and Git APIs to the base API.
- Move caching up to the base level.
- Store symbolic name and resolved name separately, so we can re-resolve the correct commit from the symbolic name after dirtying caches.
- Rename `supportsRelativeLocalCommit()` to `supportsCommitRanges()` (old name wasn't very good, and not consistent with new terminology like the `--base` flag).
- Rename `getRelativeCommit()` and `setRelativeCommit()` to `getBaseCommit()` and `setBaseCommit()`.
- Introduce `reloadCommitRange()` and call it from `reloadWorkingCopy()`.
I think this fixes the problem in D4049, and provides a general solution for the class of problems we're running into here, with D4096. Specifically:
- We no longer get dirty caches, as long as you call reloadWorkingCopy() after changing the working copy (or call a method which calls it for you).
- We no longer get order-of-parsing-things problems, because setBaseCommit() reloads the appropriate caches.
- We no longer get nasty effects from calling `requireCleanWorkingCopy()` too early.
Test Plan: This is pretty far-reaching and hard to test. Unit tests; ran various arc commands. :/
Reviewers: vrana
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4097
Summary:
This method is used in three cases:
# For unit tests, to set the range to 'HEAD^' or '.^' in an agnostic way.
# For "amend", to set the range to the commit to be amended (also 'HEAD^' or '.^').
# For "patch" and "upgrade" so we don't fail just because there's an invalid "base" rule somewhere in the config when doing clean-working-copy tests.
For cases (1) and (2), introduce an "arc:this" rule to mean "the current commit". For case (3), remove the call; it is no longer necessary to check the commit range in order to do tests for the working copy state after D4095.
Test Plan: Ran unit tests, "arc upgrade", "arc patch", "arc amend".
Reviewers: vrana
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4096
Summary:
See discussion in D4049.
The getWorkingCopyStatus() method gets called from requireCleanWorkingCopy() in a lot of places, which triggers resolution of the base of the commit range. This is unnecessary; we do not need to examine the base commit in order to determine whether the working copy is dirty or not. This causes problems, in D4049 and elsewhere (we currently have a lot of fluff calls to setDefaultBaseCommit() in workflows which need to call requireCleanWorkingCopy() but do not ever use commit ranges, such as `arc patch`). This is mostly an artifact of SVN, where the "commit range" and "uncommitted stuff in the working copy" are always the same.
- Split the method into two status methods: getUncommittedStatus() (uncommitted stuff in the working copy, required by requireCleanWorkingCopy()) and getCommitRangeStatus() (committed stuff in the commit range).
- Lift caching out of the implementations into the base class.
- Dirty the cache after we commit.
This doesn't do anything useful on its own and creates one caching problem (`commitRangeStatusCache` is not invalidated when the commit range changes because of `setBaseCommit()` or similar) but I wanted to break things apart here. I won't land it until there's a more complete picture.
This creates a minor performance regression in git and hg (we run less stuff in parallel than previously) but all the commands should be disk-bound anyway and the regression should be minor. It prevents a larger regression in `hg` in D4049, and lets us do less work to arrive at common error states (dirty working copy). We can examine perf at the end of this change sequence.
Test Plan: Ran unit tests, various `arc` commands.
Reviewers: vrana
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4095
Summary:
This allows using new methods without the need for bumping version number.
The usage is not neccessary because we already bumped the version number for this but I wanted to have a callsite.
Test Plan:
Made a typo in method name, then:
$ arc lint --only-new 1
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4193
Summary:
This changes arc land's hg support to allow you to land a branch or bookmark that has nested branches/bookmarks. Example:
// Initial state:
// -a--------b master
// \
// w--x mybranch
// \--y subbranch1
// \--z subbranch2
//
// arc land --branch mybranch --onto master :
// -a--b--wx master
// \--y subbranch1
// \--z subbranch2
Test Plan:
Created several repos like in the summary and ran 'arc land' and 'arc land --keep-branch'. Did this with both bookmarks and named branches. Scenarios tested:
- mybranch having no child commits
- mybranch having a child branch with several commits
- mybranch having two child branches
- mybranch having a child branch which has two more child branches
No code was added outside of a "if ($this->isHg)" so I didn't run git arc land.
Reviewers: epriestley, dschleimer, bos, sid0
Reviewed By: dschleimer
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4089
Summary:
See chatlog from https://secure.phabricator.com/chatlog/channel/%23phabricator/?at=37257
Basically, the install's developers sometimes use "git merge master" instead of "git rebase master" to pull changes from master into their branch. When we run "git rebase master" at the end, this creates a lot of conflicts.
Instead, optionally run "git merge master". This should be equivalent in our case (where we always rebase) and much better in their case (where they sometimes merge).
We're both going to use it for a bit and see if it creates problems. If it improves the "sometimes-merge" workflow without affecting the "always rebase" workflow, we can make it a default. If it improves theirs but damages ours, we can keep it a flag/option. If it's just terrible, we can figure out something else.
Test Plan:
Ran `arc land --mergeup --trace <feature> --keep-branch --hold`, see P624 for output. Observed merge update strategy and general success.
Also verified the conflict:
$ arc land --mergeup --merge
Usage Exception: Arguments '--mergeup' and '--merge' are mutually exclusive: The --merge strategy does not update the feature branch.
Reviewers: btrahan, vrana, DurhamGoode
Reviewed By: btrahan
CC: aran, keir
Differential Revision: https://secure.phabricator.com/D4080
