PFA: Fix magic method resolution

[arnaud-lb]

We conveniently set the scope of generate PFA closures to the function's scope as this allows const exprs referencing self:: or parent:: to behave normally:

class C {
    const VAL = 1;
    function f($a, $b = self::VAL) {}
}

$f = (new C)->f(1, ...);

// Generates the following closure with scope=C:
// self::VAL resolves to C::VAL due to scope.
$f = function ($b = self::VAL) {
    $this->f(1, $b);
};

However this affects method resolution for magic methods:

class C {
    private static function priv($a) {}
    public static function __callStatic($name, $args) {}
}

// Sees only C::__callStatic() 
$f = C::priv(?);

// Generates the following closure with scope=C: 

$f = function ($arguments0) {
    // Sees C::priv()
    static::priv($arguments0);
};

Fix by using the actual scope for PFAs of magic methods.

This should be enough as long as the generated closure doesn't inherit any self:: or parent:: expression from the magic method. Currently that's the case. If this changes we may need to rewrite these expressions, which I would like to avoid as this increases complexity and maintenance overhead a bit.

The test magic_scope.phpt demonstrates the issue. default_arg_scope.phpt just checks relative-class resolution in default argument values.

Bug found by Ryan @ Calif.io

[Girgias]

I can't see any problems with this.

One question: would resolving self/parent at compile time for traits remove the possible concern about needing to rewrite?

As I cannot see this really being a problem with an unbound closure being partially applied. But maybe I'm missing something.

[Girgias]

Well, I was trying to resolve them at one point, but was hitting issues with the JIT. So I guess this might be revisited at one point.

[Girgias]

This matches more what:

<?php

class C {
    private static function priv($a) { echo "private priv\n"; }
    public static function __callStatic($name, $args) { echo "trampoline $name\n"; }
    public static function foo() {}
}

// Sees only C::__callStatic() 
$f = C::priv(...);
echo (string) new ReflectionFunction($f);
$g = C::foo(...);
echo (string) new ReflectionFunction($g);

produces (although that output is also a bit confusing):

Closure [ <internal> static public method priv ] {

  - Parameters [1] {
    Parameter #0 [ <optional> mixed ...$arguments ]
  }
}
Closure [ <user> static public method foo ] {
  @@ /in/AItpa 6 - 6
}

[arnaud-lb]

One question: would resolving self/parent at compile time for traits remove the possible concern about needing to rewrite?

Yes, if self/parent in const exprs is resolved at compile time (or inheritance time), I believe that it would remove the need to rewrite.

[Girgias]

One question: would resolving self/parent at compile time for traits remove the possible concern about needing to rewrite?

Yes, if self/parent in const exprs is resolved at compile time (or inheritance time), I believe that it would remove the need to rewrite.

Might be worthwhile to spend some time again on it and try to resolve the JIT issues.