I think using FileLock is pretty reasonable. It's a little gross, but I'm not aware of any way to do this synchronization in make itself (although it's possible there is one), and if the process doesn't have write access to the lock it isn't going to be able to run make anyway, so it shouldn't be adding new failure modes.

I can sorta fix with using PhutilFileLock, but it feels a bit gross. Here is something I threw together real quick: https://secure.phabricator.com/differential/diff/33545/

Missing finally support is now starting to affect a large portion of my colleagues.

Another option is to add the following to .gitattributes:

I considered putting a getClassName() method on the XHPASTNode class, but I'm not entirely convinced that this is a good idea.

The same thing applies to ArcanistDuplicateKeysInArrayXHPASTLinterRule.

This was sorta fixed by D12922.

Actually, nevermind... my development install was a bit old. I can replicate this on my development host.

These changes fix it:

diff --git a/support/xhpast/scanner.l b/support/xhpast/scanner.l
index 28cf40f..bbdde72 100644
--- a/support/xhpast/scanner.l
+++ b/support/xhpast/scanner.l
@@ -313,8 +313,8 @@ NEWLINE ("\r\n"|"\n"|"\r")
   "("{TABS_AND_SPACES}unset{TABS_AND_SPACES}")" tok(T_UNSET_CAST);
 }

Yes. My clever plan is to wait for mobile devices to have an effective resolution of 3600x8200 and MindMouse technology.

after the IPO

I'll show you! I'll make this the greatest mobile app the world has ever seen!

Yea, there are just certain things you can't make mobile friendly, I think this may be one of them.

This is "working as intended" on mobile. We should maybe mark XHPAST as developer/prototype or something.

Oh, I forgot to change that.

Thanks - seems that had failed to upgrade for a while now. Problem solved.

Update libphutil, it seems that you are not using the latest version.

I tried to give this a go, but with no luck:

Yeah, it did indeed. D11268 does solve the issue correctly for me in all cases I tested.

I expect that patch breaks this:

FWIW, this patch fixes it for me

diff --git a/support/xhpast/parser.y b/support/xhpast/parser.y
index 1697c26..e07704b 100644
--- a/support/xhpast/parser.y
+++ b/support/xhpast/parser.y
@@ -1176,7 +1176,7 @@ class_statement:
     yyextra->expecting_xhp_class_statements = yyextra->old_expecting_xhp_class_statements;

Here's a very basic test I did for profiling XHPAST against PHP-Parser:

A related case with try..catch..finally (see D10337) works in the same way as @epriestley described. However, in that case it's easy to fix. This may be less trivial, but still worth fixing.

This is not a syntax error, per se, in PHP -- the error would say something like "PHP Parse error: syntax error, unexpected 'final'..." if it was. I think it gets raised a little later on in the compile phase. So that's the technical reason why we don't detect it.

I don't mind working on this, but I'm not sure what the correct fix is.

@epriestley: could you take a look at the comment above? I'd push out a diff but for some reason the values of the tokens change when I rebuild xhpast.