Trivially rebased for landing

Feel free to test against secure within reason if that's easier. These patches might not seem like a big deal, but stuff like this which just makes my life easier is incredibly rare, so make yourself at home.

In trying to arc diff --update this I got an exception (but it worked with --head, which I had been using to submit each commit of the patch series). What's the best way to test out arc itself and reproduce that? Use admin.phacility.com to get a testing instance?

In D21496, declaring a method private final (which is redundant, as a private method may never be overridden) causes an issue in PHP8.

Ah, great. Making this variation of the change will probably never actually matter compared to the first version, but I'll sleep at least a little better at night.

In D21497#272834, @epriestley wrote:

What's the specific issue you run into with PHP8 with the existing code -- the function emits a deprecation warning when called?

Since the attack surface on the XML entity loader is huge/scary (historically, see D8049), I'd prefer to continue explicitly disabling it if we can. Although there's probably no real risk, I can imagine scenarios like some distro shipping a version of PHP which enables it by default, or users enabling it by default because they run some other software that needs it alongside Phabricator. In these cases, we're a little better off at runtime if we continue disabling the loader.

If this just raises a deprecation warning under PHP8, I'd be more comfortable "fixing" it by suppressing the warning with @ (so @libxml_disable_entity_loader(true); -- not sure how familiar you are with PHP) so that we're still making sure the loader is disabled. Is that reasonable, or does it create more problems?

Suppress deprecation warning with @ rather than skip the function call.

It's possible that third party code which installs custom error listeners via setErrorListener() that expect 'context' to be populated may exist, I'm not aware of any such code and think it probably does not exist. It would also be easy to update any such code in response to this change, so I think it's not worth retaining backward compatibility with a dummy parameter and that this is the most-desirable version of this change.

What's the specific issue you run into with PHP8 with the existing code -- the function emits a deprecation warning when called?

I added you to Blessed Committers, so you should be able to arc land this yourself. See the description of that project for more detailed instructions, or let me know if you run into issues. "Land Revision" here in the web UI should also work, or I can just pull it for you if that's easier.

Thanks! There are some similar linters already (e.g., for final in a final class, or final on an abstract method) but this particular combination (private + final) slipped through. I'll add a linter so these don't get re-introduced and apply an equivalent change to Phabricator.

Just want to add a note that with git lfs managed files, arc patch won't work unless one fetch the ref tag and then the lfs blobs from the staging server first. See https://discourse.phabricator-community.org/t/arc-patch-fails-with-git-lfs-files/2447/3

As of macOS X 11 (Big Sur), php on the CLI emits:

That seems reasonable. I also ran into a couple of other suggestions elsewhere:

Off the wall suggestion: how about a trigger that sets the subtype:

Trailing slash

Seems reasonable, definitely the highest impact-per-character change I can come up with.

The profiling in D20566 seems satisfactory, and has been useful in resolving or understanding a few performance-related issues.

On my personal resource limited RasberryPI alike server (4x1.2ghz ARM A53, 2GB ram, php 7.4.12) running Phabricator - this changes saves ~15ms of runtime (180ms vs 167ms after) when running:

./bin/herald test --object T19 --type HeraldManiphestTaskAdapter

Rebase

This change is probably no longer relevant with recent large refactoring of arcanist

• There is no way to pull custom field values with *.search. See above.
  • There is no way to edit non-custom field values with *.edit. The underlying transactions haven't been modularized yet; they should be, then EditEngine should get appropriate EditField definitions.
  • There's no way to identify which custom fields can be edited. This overlaps with T13248, but is also a Conduit API Console UI problem. The web UI should have some way to inspect parameter variations per object subtype for available subtypes.
    • As a workaround, you can try to edit an invalid field. The error message will identify valid fields.
  • There's no way to create steps with *.edit because you can't specify a step type. See T13449 for a general variation of the "type is required to initialize objects" problem.

• Use more consistent capitalization.

HarbormasterBuildStepCoreCustomField emits no fields if a BuildStep has no attached Implementation object. This dates from D15352 and is conceptually reasonable ("don't crash if a build step exists but the implementation no longer does") but should probably be represented differently (e.g., an explicit "InvalidImplementation").

This appears fixed by D21484 (and @20after4 confirmed the fix on rPc0414732 -- thanks!) so I'm going to mark it as resolved.

See https://discourse.phabricator-community.org/t/strpos-throwing-in-phabricatorauthpasswordengine/4335, and D21477.

This has been tested in wmf production and the fix is working.

Ah, thanks for the pointers!

In D21484#272642, @epriestley wrote:

Minor nitpicks inlines, I'll just tweak them locally as I land this.

(Since this wasn't submitted with arc, the Git "Author" information has been lost and the commit will be incorrectly attributed to me as an author. If you submit further patches, you can use arc to retain authorship information if you'd like.)

Minor nitpicks inlines, I'll just tweak them locally as I land this.

I know it's an old thread, but I am encountering what is, as far as I can tell, exactly the same issue. I'm on the latest version of trunk (~Oct 26) with php 5.5.9 on Linux 3.13.0. I also observed the issue on the May 30 version.

I think I've got a small tidbit to add on a specific use-case with Jenkins. I had been using pipeline builds which are working nicely but I just tried to setup a multi-branch pipeline build and this requires the branch name in the Jenkins URL of the HTTP request triggering the build. I suspect in this case the proper thing to do would be to trigger and build twice. I guess that's more of an on-branch-change sort of situation than on-commit and using those triggers in Herald (they look to be present, I haven't used them) and having that information passed on to Harbormaster as mentioned could fill the need.

@epriestley - empty inline comment with suggestion renders rather peculiar transaction which is somewhat confusing and odd... Any plans on tackling it? Like See context greyed out...

Same issue here.