$ arc patch D127907
Exception
preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated
(Run with `--trace` for a full exception trace.)
This is caused by a deprecation warning being treated as an error. I really hate that I have to know anything about PHP to handle code reviews in LLVM, but apparently, this starts happening after an upgrade to PHP 8. I am already using arcanist as cloned from git, so I just applied the following patch to tell it to use the default error flags (which at least on my machine, disable deprecation warnings in php.ini).
diff --git a/support/init/init-script.php b/support/init/init-script.php
index ad40b8bd..5da2e045 100644
--- a/support/init/init-script.php
+++ b/support/init/init-script.php
@@ -15,7 +15,7 @@ function __arcanist_init_script__() {
ob_end_clean();
}
- error_reporting(E_ALL | E_STRICT);
+ //error_reporting(E_ALL | E_STRICT);
$config_map = array(
// Always display script errors. Without this, they may not appear, which is
Just FYI, for arc diff the following patch may be needed for some newer PHP versions
diff --git a/src/workflow/ArcanistDiffWorkflow.php b/src/workflow/ArcanistDiffWorkflow.php
index 7201a003..808dc9bd 100644
--- a/src/workflow/ArcanistDiffWorkflow.php
+++ b/src/workflow/ArcanistDiffWorkflow.php
@@ -2360,6 +2360,9 @@ EOTEXT
// If we track an upstream branch either directly or indirectly, use that.
$branch = $api->getBranchName();
+ if (is_null($branch)) {
+ $branch = '';
+ }
if (strlen($branch)) {
$upstream_path = $api->getPathToUpstream($branch);
$remote_branch = $upstream_path->getRemoteBranchName();
It’s also quite straight-forward to use the Phabricator API for the main tasks. For example, I’ve been using the following script as replacement for arc patch: ⚙ D73075 [utils] Add initial llvm-patch helper to manage patches. (with the caveat that it only supports patches that apply cleanly)
I’ve had some success using moz-phab to interact with Phabricator instead of arcanist. I haven’t switched to it as my daily driver yet out of sheer laziness, but it worked pretty well for everything I tried.
If we get some +1’s on daily use of moz-phab, I think we should change our docs to recommend it. Arcanist is aging badly and i daresay it is none of our ambitions to know much about php in order to submit code to llvm.
I’m in the same boat – haven’t used it but am tired of trying to keep arcanist patched across my setups. @River707 do you recall if it was harder than just RTFM and install/go?
If we’re moving to GitHub reviews, then yeah, nothing needed here. I had somewhat stopped paying attention to the status of that and assumed that someone would announce the plan and date – which looks like it has been done. Still 1y+ out. That still leaves a lot of room for arcanist pain for developers. If moz-phab is working, I think it would help folks if we wrote that down as an alternative to arcanist at the least.
Just to comment, if arcanist doesn’t work, the plain upload a patch through the web interface one does. For most folks, I suspect arcanist is overkill.
I might just be thick, but I did do this the last time arcanist gave me problems – and I thoroughly messed everything up. Somewhat embarrassing to admit, but I may have grown dependent on the overkill.
A manually uploaded patch is probably what caused the tool to fail in the first place in my case. arc patch will not only apply the patch but also include the reviewer and review link which is kind of useful when I need to commit other people’s patch.
Telling everyone to manually upload the patch might just mean to kill arc, at least don’t run it with php 8.
Doesn’t arcanist upload some additional metadata as well (i.e. the base commit)? Agreed - the flow to be able to apply someone else’s patch (or my own on another machine) is something I rely on a lot and I fumble it a lot when it doesn’t work.
Maybe we should fork arcanist and apply all patches there instead? We are still going to stick with Phab for a year - so making it easier for new people to get arc is important.