Closed
Description
use std::self; // error[E0429]: `self` imports are only allowed within a { } list
we should offer the suggestion to remove ::self
, as this is likely what the user intended.
This issue has been assigned to @mibac138 via this comment.
Metadata
Metadata
Assignees
Labels
Area: Suggestions generated by the compiler applied by `cargo fix`Category: An issue proposing an enhancement or a PR with one.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Relevant to the compiler team, which will review and decide on the PR/issue.Relevant to the language team
Activity
Centril commentedon Aug 20, 2019
@petrochenkov Would it simplify or complicate things if we simply allowed this instead of rejecting it?
petrochenkov commentedon Aug 20, 2019
~Simplify.
Centril commentedon Aug 20, 2019
Might be worth doing that in that case.
(Although
use foo::bar::self;
is less clean from a readability perspective but perhaps that should merely be a lint.)petrochenkov commentedon Aug 20, 2019
It needs some amount design work though (not large).
The idea is to treat
self
andsuper
in Rust paths as.
and..
in filesystem paths.Some questions arise in the process, e.g. if
bar
is an import (symlink), then whose parentbar::super
refers too, or whetheruse foo::super [as name];
is allowed without theas name
part and what name it introduces (use foo::self;
needs to be allowed for compatibility and introducesfoo
).Also cc #48067 (path concatenation in macros).
nikomatsakis commentedon Aug 29, 2019
Visited in compiler triage. I think this is medium priority, clearly, but I am guessing that @Centril intended the nomination for the lang team.
Wearing my lang team hat, I think I'd expect this to compile, but I don't have strong opinions about it.
nikomatsakis commentedon Sep 5, 2019
We discussed this in the lang team meeting last week. We decided that there were some reasons to tread carefully here: in particular, we didn't really want to admit the possibility of "non-canonical" paths like
use foo::bar::self::super::bar
. Moreover, there isn't a strong reason to accept this pattern -- it would definitely be linted against, and if you have some kind of tooling that wishes to emitself
for simplicity, they can always emit things likeuse foo::bar::{self}
.So the conclusion was "probably better to just leave it alone for now" from a language perspective.
If we were to accept
foo::self
, we'd want some conditions:comex commentedon Mar 23, 2020
In addition to a suggestion, the compiler could have better error recovery. Currently, the following produces errors on both the first and second line; it should only error on the first line:
mibac138 commentedon May 3, 2020
@rustbot claim
use foo::self
#71863Rollup merge of rust-lang#71863 - mibac138:self-import, r=estebank
Rollup merge of rust-lang#71863 - mibac138:self-import, r=estebank