Global paths in use directives can begin with super or self

[jseyfried]

For example,

mod foo {
    fn f() {}

    fn g() {
        use ::super::foo::f; // This is currently allowed,
        ::super::foo::f(); // but this is not.
    }
}

[vlastachu]

What semantic are you expecting (question for anyone who read there)? Compiler looking for top-level entity named "super" and not founds and says that you probably want to export "super".

Btw if I wrote mod super{} parser says that identifier expected, keyword found. So, in expression ::a::b::foo() a, b and foo should be expressions and parser should give similiar error like "identifier expected...".

I would be prefer to fix it, if it is an error.

EDIT. Sorry. I am read your issue again and understand that use ::super::foo::f; has absolutely wrong semantic. This statement is really looking entity in super context, but should looking in top-level super.

Both errors (possibly wrong message about error and super context that ignoring double-colons at begin) is may be solved by checking for keywords in "::foo::bar" statement.

Actually next links in chain "::self::self::self" is checked by parser.

[jseyfried]

Both errors (possibly wrong message about error and super context that ignores double-colons at beginning) may be solved by checking for keywords in the "::foo::bar" statement.

Agreed, I think that is the best way to fix this issue.

I would prefer to fix it

That would be great, let me know if you have any questions!

[steveklabnik]

@rust-lang/lang, do we plan on having some sort of semantics for this, or is this just a bug?

[nikomatsakis]

I think the fact that ::super:: is accepted is just a bug.

[vlastachu]

Hello.
Some summaries about my work.

1. That behavior can be seen on any special identifier: self, static, super, Self. There is also identifiers that I don't know: tt, matchers, prelude_import. Now I assume that my point is self and super.
2. Also use a::b::self::super says that can't find self or super.
3. In spite of my expectations parse::token::Token::is_keyword, is_any_keyword returns false. Because they waiting for Plain identifier and getting ModName. So I add parse::token::Token::is_special_ident_in_modname
4. parse::token::Token::is_strict_keyword checking for self or super in ModName context, but not useful for me.
5. There is parse_ident_or_self_type and parse_ident functions. Their names sounds like they don't accept special identifiers. If I add check for special identifiers in ModName context it will solve the current problem. But it will fail on use self::.... So this is hard way.

Yesterday I commit my changes that fix something. The thing is that issue can be divided into two different tasks.

The first

the fact that ::super:: is accepted is just a bug.

And it already solved via ad-hoc checking in global context

if is_global && self.token.is_special_ident_in_modname() {
    return Err(self.fatal(&format!("expected identifier, found special identifier `{}`",
                               self.this_token_to_string())));
}

Error message probably should be replaced by more general "expected identifier, found keyword". Adding some comments and it may be pull requested.

The second task is more general: wrong error message. rustc is really looking for crate or module named self or super. We may say that the real code is not containing such paths and if it contain - it is typo and will be found at compile-time.

But in case if error message is important:

1. parse_ident should forbid any special idents as written above.
2. In case if it is must allow (first token of not global path or something else) write additinal function like parse_ident_or_self_super and call from upper functions.