Differences of syntax analysis between cc-mode and php-mode

[periklis]

Hi,
we are currently working at my current project on an extended version of symfony coding standards. I took this week the effort to implement add a c-style to cover the differences. However, while i was groking the cc-lang.el internals to understand the syntax analysis, i noticed differences in the analysis of function symbols to my beloved php-mode. Let me explain:

Our style demands to add a newline before and after the opening brace on a function declaration. The position before the brace but after the argument list should be syntactically func-decl-cont. The position after the brace should be defun-open. However, the helper c-echo-syntactic-information-p tells me that the first is ((inclass) (top-most-intro xxxx)) if the brace is typed on the function declaration line. If the brace is typed on a newline after the function declaration the syntax analysis says ((inlambda) (inline-open xxxx)). Hence, i cannot use the correct symbols in c-hanging-braces-alist. For example:

public function funcName($args) { // This brace belongs on a new line
}

Although, php-mode inherits any c-styles from java-mode some function symbols are missing namely defun-open, defun-close, func-decl-cont or are found as inlamba. Why is this so? Are we missing anything in the c-lang-defconst stuff in php-mode?

Furthermore, i noticed differences in the syntax analysis of arrays with braces-notation:

$arrayWithBracesNotation = [
    "key1" => "value1",  // Syntax analysis says at point: ((arglist-cont xxx))
    "key2" => "value2",
];

Why does the syntax analysis say that we are in an arglist-cont symbol?

I know that defining own styles is against the usage of standards. However, since we append only some styles to symfony coding standards, we are sticking with them anyway. So, i would like to understand the above differences beyond fixing my style. Can/Should we enhance the syntax analysis? Is this appropriate for such a case?

[jorissteyn]

Hi Periklis, those are good questions!

The position before the brace but after the argument list should be syntactically func-decl-cont.

Maybe, cc-mode implements this for throw specifications in C++ and java:

void foo() throws X,
                  Y // func-decl-cont

You could argue php-mode should do this:

function foo() 
    : int // func-decl-cont

But I think that's an uncommon way to declare a function so it might not be worth the trouble implementing it.

The position after the brace should be defun-open. However (...).

You're right. It actually worked pretty well until we tried to support closures. Closures are currently handled by registering the function keyword in c-lambda-kwds. That made all related tests (like issue-19, issue-29) pass but unfortunately makes cc-mode consider regular functions closures too.

I tried to come up with a better approach and I might have achieved just that, see my branch issue-291.

In summary, I did this:

• allow easy testing of syntactic symbols in test cases
• add test case for defun-* symbols
• remove function keywords from c-lambda-kwds
• fix indentation of closures inside argument lists (test(function() {});)
• fix indentation of closures in statements ($test = function() {};)

Feedback is very welcome! I'll try using the branch in my regular workflow to see if it works as expected and do a PR eventually.

Why does the syntax analysis say that we are in an arglist-cont symbol?

That should be fixed, it's like issue #289 where you'd expect a statement-cont but get an arglist-cont. Easier said than done, I think we should define a new symbol for arrays, something like:

array(
    1, // array-intro
    2, // array-cont (or array-entry like brace-list-entry)
    3 && 4 // array-cont
        || 5, // statement-cont
   6, // array-cont 
)

And then the same for short array notation.

Can/Should we enhance the syntax analysis? Is this appropriate for such a case?

Yes, we use cc-mode so we can leverage all the features it brings. If you can do something in any of the cc-mode major modes, but not in php-mode, consider it a bug.

[ejmr]

You could argue php-mode should do this:

function foo()
    : int // func-decl-cont

But I think that's an uncommon way to declare a function so it might
not be worth the trouble implementing it.

I am beginning to see such declarations more often and have started using them in my most recent PHP work. Right now, when using the php CC Mode indentation style, PHP Mode indents that example just like presented. However, the : int line is tagged as lambda-intro-cont. Semantically func-decl-cont seems the more accurate choice. I'm not sure what immediate benefits we may gain from the change, but just from sifting through old open issues, this caught my eye as something worth consideration now.

If you can do something in any of the cc-mode major modes, but not in php-mode, consider it a bug.

I agree.

[ejmr]

I am sorry that this issue has been here for over one year. But because of that I believe we need to re-evaluate the concerns. More specifically, since this issue was reported, has the general consensus in PHP programming adopted a common style for function declarations like the kind described in the posts above? If yes, or even no, we need to reconsider changing the default indentation of PHP Mode to be closer to CC Mode, and frankly we can probably find some more features of CC Mode that we have let fall through the cracks.

[periklis]

@ejmr Function declarations using type hints are common on modern code bases but not the single major pattern yet. Afaik, type hints are not even used extensively in major php frameworks. At least the last time i looked at theme couple of months ago. However, my initial observation was that writing your own add-c-style does not match with the expectation of cc-mode keywords like func-decl-cont. Thus, writing your styles for php-mode needs more try-and-error than in other cc-mode-based modes, because the original keywords are syntactically matched different. Nevertheless writing your own add-c-style is a less common job. Hence, if it is hard too hard adapt php-mode to cc-mode then it is ok for me to drop this issue and just document the differences in the README.md

[ejmr]

@periklis Thank you for the info.

Thus, writing your styles for php-mode needs more try-and-error than in other cc-mode-based modes, because the original keywords are syntactically matched different.

The switch to redefining much of PHP Mode on top of CC Mode has been going on for quite a while and is still incomplete. And we should do better unit testing the styles we provide. Having said that, we use c-lang-defconst to define many semantic elements of PHP but we do nothing with func-decl-cont. We should address that, although I am certain it will take some experimenting, as many of the CC Mode settings have.

Hence, if it is hard too hard adapt php-mode to cc-mode then it is ok for me to drop this issue and just document the differences in the README.md

I would not call it "hard to adapt", but I have to admit that using CC Mode as our foundation has had a lot of far-reaching effects that I don't think most people predicted---I didn't anyways. Still, the scope is wide, but I feel like it is more of a challenge of effort and not a challenge of complexity. So we can experiment with adapting func-decl-cont and I'm confident we can find a good behavior and presentation.

And it is true that adding a C style is uncommon. Documenting the differences between CC Mode's general behavior with PHP Mode's is a great idea; it would provide an impetus to also re-evaluate a lot of how we are using CC Mode. I am considering also taking that idea one step farther and writing a simple tutorial (if possible) in the README for defining/customizing PHP styles based on CC's.