Ignore any tokens within classes when looking for namespaces

[asgrim]

This should resolve issue #8

Basically, this proposed solution looks for classes, looks for the first opening brace, then keeps iterating until the same-level closing brace is found, then we continue.

I may've missed a use-case with this, but I think on the surface this should work - happy for any feedback given :)

[asgrim]

Not sure why Scrutinizer thinks the tests failed.. looks okay on Travis I think?

[Ocramius]

Is there a class constant for opening and closing brace?

[stof]

AFAIK, no. (well, there are constants for some opening braces depending on the reason why they are opened).
Btw, this should be looked at carefully for interpolation in strings as the opening token may include more than just the opening brace

[mvriel]

There is no class constant but it would not hurt to introduce it; though I do not consider it blocking for a merge

[nikic]

The relevant tokens should be T_CURLY_OPEN and T_DOLLAR_OPEN_CURLY_BRACES.

[mvriel]

Sorry but those constants are string-based curlies and always include a dollar sign (see http://php.net/manual/en/tokens.php); the curly braces for functions and classes are literals and AFAIK do not have a constant

[asgrim]

Nice idea, but this wouldn't work, you can have a use that follows a class within the same namespace, see: http://3v4l.org/uiEWd :/

[nikic]

@asgrim However this use would only take effect for classes defined after it. If you want to properly handle that you need to specify the class name you are targeting.

[asgrim]

@nikic it may not be valid PHP and not be able to execute, but it seems that if you perform a token_get_all() on this, it will still give you valid tokens (even if it won't execute):

namespace A {
  class Foo {
    function a() {
      echo 'A\Foo';
    }
  }
}

namespace B {
  class Foo extends Bar{
    function a() {
      echo 'B\Foo';
    }
  }
  use A\Foo as Bar;
}

In this edge case where tokenizer will happily tokenize this, the depth-checking method I've implemented (and improved in a soon-to-be-opened-PR) would be safer.

[nikic]

@asgrim It's perfectly fine PHP and will work. What I'm saying is that use statements only affect all classes after them. So if you have this code:

class A extends X {}
use Foo\X;
class B extends X {}

Then class A will extend X, while class B extends Foo\X. So if you want to correctly handle this, you have to pass in the class name you're considering (rather than just its namespace name) and only return the aliases that are in effect at the time of the definition of the class.

(So yes, you're right, I'm just pointing out an extra caveat why it won't work out of the box, even if you properly do the skipping here.)

[asgrim]

@nikic Ah yes - I see what you mean, you are absolutely correct. I've reported as a separate issue in #11 as this is not something that is introduced by this PR, the issue would've existed already in TypeResolver.

[stof]

Regarding the scrutinizer issue, this is because the first job to finish was the PHP 7 job, which was not able to generate code coverage (no XDebug on PHP 7 for now as it is not migrated yet). Given that you still ask ocular to upload the code coverage on PHP 7, it notified Scrutinizer that the coverage data were missing (the message in the scrutinizer UI is a bit misleading as it is not about test failing but about coverage not being available)

[mvriel]

I am missing an @covers statement with this test; meaning that coverage will potentially show a skewed number of lines that were covered

[mvriel]

@asgrim @Ocramius I am going to merge this item since it does not seem to contain any functional issues. I would however appreciate it if the comments mentioned above can be resolved in a follow up PR