For what it's worth, the only reason I was trying to figure out stuff with the built-in server was because at the time trying to get Phabricator running in Docker correctly was... not nearly as easy as I would have liked. Quickly skimming online suggests that's improved in the interim.

Just a note for the above - the initial DB seed script will need to be updated accordingly as well. Right now, trying to perform a clean install on a 2nd-gen Google Cloud SQL instance (which has the above limitation) simply errors out when it reaches one of the tables coded as MyISAM.

Noted. This is by no means an urgent thing (I have a Composer package to mostly the same effect, it just seems silly to be maintaining it twice), and all else being equal I'd rather spend time thinking about the bigger solution. But in the name of all things holy, please don't reinvent Composer as T5055 is basically getting at.

I'd like to get some feedback on the initial implementation, I'll go back and address the couple of TODOs. Note that the change to PhutilUnitTestEngine and one change in ArcanistConfigurationDrivenUnitEngine are actually D15880 because I branched from the wrong place.

I'm trying to get the PHPUnit engine working with .arcunit, like the phutil engine. Without this change, the results will never render unless the engine renders its own results (as phutil currently does). The Arc Unit workflow itself skips rendering the overall results since ArcanistConfigurationDrivenTestEngine::shouldEchoTestResults() returns false, as it contains logic to render results (changed in this diff).

After applying the diff locally, in PhutilUnitTestEngine change shouldEchoTestResults to return true (or comment out the addition entirely, since the parent does the same):

In D15678#183376, @epriestley wrote:

(That sounded really self-congraulatory, but it took me a lot of work to come up with the node tree + token list approach!)

Related: it may be worth looking into leveraging the native AST going forward instead of trying to keep xhpast in sync with PHP with every new minor release. I'd wager it wouldn't take too much voodoo to convert between them so that the existing linter rules continue to work.

Thanks!

Implementation of what's described above - also seems to provide the expected results in my case, and limits impact to PHPUnit results. If a file is executed at all, it should show up normally; when completely untouched (which tends to show up with phpunit whitelisting, now necessary in the newest versions).

That seems totally reasonable. It seems like a bit of a stretch for PHP code specifically, but sane as a general-purpose answer.

Turns out this is actually illegal (as I thought):

In D9792#25, @epriestley wrote:

This looks great to me, but I think I came up with a "clever" construction it gets wrong.

My word, why would they allow syntax like that? I'll write a test case for it and see what happens, but that's probably just "give up you damn fool" territory :)

This looks good to me - I'll update D9791 and D9792 to use the updated interface once this lands

• remove snippet from testing

• making diviner namespace aware
• clean up a lot of the normalization and language-specific context separation logic
• more cleanup

Remove hanging vim swapfile

• further clean up namespace/context work
• add php atomizer test cases and fix an issue they exposed

Significant cleanup to NS range detection for weird files that do evil things. Fixes line numbering issue, and now includes class name in the context for method declarations

Just discovered that this screws up the line numbers from the source file since it rebuilds the tree during parsing. This feels like an incredibly wrong way to select, effectively, a few branches out of the AASTTree, but I couldn't find anything better in the source to handle it.

Perform some crazy slizing and dicing to handle a format that PHP never should have supported:

Cool, thanks for the feedback!

Some screenshots of this in action:

Thanks @chad :)

(I don't have push access - need you to land this)

Works here too :)

Also tested that incorrect credentials fail. Because, you know, security. All looks good here!

Worked on my install combined with D8723 :D

The number of tickets you know off the top of your head never ceases to impress. Yeah, that's exactly it. I'll happily test a patch on our install. Thanks!

Turns out this actually killed our LDAP integration, we just didn't spot it until someone nuked their session and tried to log in again.

Ah, yes, that makes some amount of sense. I saw chaining_dereference: defined in the php parser that looked related, that's probably what it made work. That one gave me an unusually bad headache trying to decipher the zend states for some reason.

I just ran into that one in practice today, so I'll probably take a crack at another grammar update to handle it in the next 48 hours or so.

Found another issue with some array dereferencing: if ($state && !isset(self::getSearchStates()[$state])) { still fails. I'll look into that one a bit later - once I saw what the zend grammar was doing... ick.

Update here - did spot one issue: (new Foo)->bar (added in 5.4) fails:

Just as an update - so far all of the changes I've tested have been working really well for 5.4 source. The stock symbol generation script seems to not mind files with more modern grammar ($x = [];, trait, use, closures, etc), and the XHPAST linter seems ok too. As you'd expect we have a massive number of files in our codebase seeing that it started close to five years ago so naturally I haven't been able to run it on everything but I'm feeling pretty good about this :)

This is incredible, thanks! Our devops team is going to comb through all of this and the reviews and see if we need to take a crack at anything else.

Sounds good. We're trying to push everyone through the arc workflows for everything so if it's still a legitimate issue I should have an update pretty soon.

Ok, --background 0 DID allow it to go through. I don't have the stack from SIGHUP as apparently she doesn't have the pcntl extension installed either (I can get it installed if necessary, although given that your first instinct was right I'm guessing it probably isn't...)

Ah, gotcha. I just confirmed that the developer that reported the issue to me doesn't even have xdebug installed, so it's definitely not the listener. However I told her to grab me the next time it happens (it *was* originally being run completely normally), so I'll upload a new trace with the SIGHUP trick when I have one.

Super weird. On a new branch to reproduce the issue it submitted the diff just fine (although still hangs if I arc diff --recon --no-diff manually)

I never explicitly set it up on my machine which exhibits the problem, but I thought I saw something for eclipse running on the machine we first spotted the problem from.

It does not (I assume you mean on the arc diff command, as arc lint --background 0 just errors out with an unrecognized option)

Interesting. Someone on my team mentioned arc diff complaining about no content earlier, so he must have sent this one up by hand. I'd always wondered why sometimes I'd see "context not available" on diffs; I had figured it wasn't able to line something up cleanly with the previous revision/version in master/etc. Should either manually doing a git branch (as compared to arc feature) and/or pulling in changes from master daily have any impact on its use?