Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't import super #29036

Open
wthrowe opened this issue Oct 13, 2015 · 6 comments
Open

Can't import super #29036

wthrowe opened this issue Oct 13, 2015 · 6 comments
Assignees
Labels
A-resolve Area: Name resolution C-bug Category: This is a bug. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@wthrowe
Copy link
Contributor

wthrowe commented Oct 13, 2015

I'm not sure if this falls into the realm of something needing an RFC or not, but I expected this to work:

mod a {
    use super as foo;
}

but it gives error: expected identifier, found keyword super``.

If I do it in an import list I get a different error:

mod a {
    use super::{self as foo};
}

error: unresolved import super. There is no superin???``

(I suppose this also applies to self, but I can't think of a reason to do that.)

Edit: This seems to work as a substitute:

mod a {
    mod foo { pub use super::super::*; }
}
@steveklabnik
Copy link
Member

@rust-lang/lang, what do you think about this?

@nikomatsakis
Copy link
Contributor

I vaguely expect use super as foo to work as well as use super::{self as foo}

This error message "error: unresolved import super. There is no super in ???" DEFINITELY seems subpar.

Manishearth added a commit to Manishearth/rust that referenced this issue Apr 24, 2016
 Paths are mostly parsed without taking whitespaces into account, e.g. `std :: vec :: Vec :: new ()` parses successfully, however, there are some special cases involving keywords `super`, `self` and `Self`. For example, `self::` is considered a path start only if there are no spaces between `self` and `::`. These restrictions probably made sense when `self` and friends weren't keywords, but now they are unnecessary.

The first two commits remove this special treatment of whitespaces by removing `token::IdentStyle` entirely and therefore fix rust-lang#14109.
This change also affects naked `self` and `super` (which are not tightly followed by `::`, obviously) they can now be parsed as paths, however they are still not resolved correctly in imports (cc @jseyfried, see `compile-fail/use-keyword.rs`), so rust-lang#29036 is not completely fixed.

The third commit also makes `super`, `self`, `Self` and `static` keywords nominally (before this they acted as keywords for all purposes) and removes most of remaining \"special idents\".

The last commit (before tests) contains some small improvements - some qualified paths with type parameters are parsed correctly, `parse_path` is not used for parsing single identifiers, imports are sanity checked for absence of type parameters - such type parameters can be generated by syntax extensions or by macros when rust-lang#10415 is fixed (~~soon!~~already!).

This patch changes some pretty basic things in `libsyntax`, like `token::Token` and the keyword list, so it's a plugin-[breaking-change].

r? @eddyb
@jseyfried jseyfried added the A-resolve Area: Name resolution label Jan 30, 2017
@jseyfried
Copy link
Contributor

c.f. #39330 (comment)

@petrochenkov petrochenkov self-assigned this Feb 19, 2017
@steveklabnik steveklabnik added T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed A-lang labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 24, 2017
@ordian
Copy link

ordian commented Sep 11, 2018

Any chance this being fixed in rust 2018?

@tv42
Copy link
Contributor

tv42 commented Jun 12, 2021

I stumbled on this today. This is clearly allowed by the grammar in reference, and either should work or the reference needs to be changed:

UseDeclaration :
use UseTree ;

UseTree :
(SimplePath? ::)? *
| (SimplePath? ::)? { (UseTree ( , UseTree )* ,?)? }
| SimplePath ( as ( IDENTIFIER | _ ) )?

SimplePath :
::? SimplePathSegment (:: SimplePathSegment)*

SimplePathSegment :
IDENTIFIER | super | self | crate | $crate

@tv42
Copy link
Contributor

tv42 commented Jun 12, 2021

Alternate perhaps simpler workaround:

use super::super::name_of_my_parent;
use super::super::name_of_my_parent as newname;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Name resolution C-bug Category: This is a bug. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants