Added support for keywords for class/method/label/declare/namespace/class const names

[bwoebi]

This patch adds possibility to use keywords at some places where previously were only T_STRING's allowed.

Example:

class List { // T_LIST, is now enabled
    public function default() { // T_DEFAULT
        // do some action
    }
}

For further examples see the rfc at https://wiki.php.net/rfc/keywords_as_identifiers

The goal of the patch is to limit less the user's choice of names for labels, classes, functions, namespaces etc.

Internals discussion at http://marc.info/?l=php-internals&m=137893452326358&w=2

---

Possible constructs (with string being a T_STRING or a keyword):

string::string;
string::string();
$var->string;
$var->string();
(modifier)* function string() { // methods
function T_STRING ((string) $var, ...) // the optional typehint
declare(string = ..., ...);
(namespace) \(string\)*string;
use string as (modifier) string; // namespace aliasing
new string;
class string (extends string) (implements string, ...) {
trait string (extends string) (implements string, ...) {
interface string (extends string, ...) {
string::…;
string: // label for goto
goto string;

What still is impossible: (as function names and constants remain unaffected)

keyword(); // fcall
keyword; // constant

[nikic]

nit: should be static

[bwoebi]

Hmpf, fixed. Had that already fixed locally, but forgotten to commit it.

[smalyshev]

why replace a working test with something completely different? If we need to test for if as class name, we can add different test, but that's not what this test was about.

[bwoebi]

@smalyshev actually a class named namespace is supported. So the test was superfluous in it's old state.

[smalyshev]

@bwoebi if it's supported, change the outcome of the test, why rewrite it to something completely different testing something else not related to the bug?

[bwoebi]

@smalyshev good question… Don't remember why I had changed the test. Reverted test now and updated expectf to match actual state.

[smalyshev]

I don't think we need to be clever here. Why not just assign CG(tokenbufsize) = ZEND_INIT_TOKEN_BUF_SIZE separately? It would be much more readable.

[smalyshev]

I think it may be better to take it out as a function. As an one-line expression it is not readable and if we'd ever need to modify it it would be very easy to do it wrong. It probably also has some reuse potential.

[smalyshev]

these two branches seem to have the same code inside, why there's two branches and not just one if with || condition?

[php-pulls]

Comment on behalf of nikic at php.net:

Closing as this RFC failed and there now is a new one.