Is there a class constant for opening and closing brace?

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

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

The relevant tokens should be T_CURLY_OPEN and T_DOLLAR_OPEN_CURLY_BRACES.

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

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 :/

@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.

@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.

@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.)

@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.

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