-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Delay gensym creation for "underscore items" (use foo as _
/const _
) until name resolution
#56392
Conversation
r? @oli-obk (rust_highfive has picked a reviewer for you, use r? to override) |
let Export { ident, def, vis, span } = child; | ||
// FIXME: We shouldn't create the gensym here, it should come from metadata, | ||
// but metadata cannot encode gensyms currently, so we create it here. | ||
// This is only a guess, two equivalent idents may incorrectly get different gensyms here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this even a hypothetical problem for _
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm... not entirely sure.
I haven't found an example where it would caused observable problems so far (assuming gensym creation is delayed until name resolution).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#56303 (comment) has an example of gensyms being created incorrectly internally, but it's not observable from the outside.
@@ -9,6 +9,5 @@ | |||
// except according to those terms. | |||
|
|||
const _: () = (); //~ ERROR is unstable | |||
static _: () = (); //~ ERROR is unstable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand this wasn't in the RFC, but I see no reason not to support it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const _: T = expr;
was permitted because it has a reasonable generalization to irrefutable patterns (e.g. const (A, B) = (1, 2);
) but does static
also have that with the same-address notion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least the motivation in rust-lang/rfcs#2526 does not apply to statics.
Constants don't even exist in MIR (AFAIK), so they can be used for compile-time asserts, while statics end up in the resulting executable/library, or need to be optimized away.
3ad864b
to
b5f441d
Compare
Updated with comments addressed. |
Prohibit `static _` Fis unused import warnings for `use foo as _` Add more tests for `use foo as _`
b5f441d
to
eb1d2e6
Compare
@bors r+ |
📌 Commit eb1d2e6 has been approved by |
Delay gensym creation for "underscore items" (`use foo as _`/`const _`) until name resolution So they cannot be cloned by macros. See #56303 for the discussion. Mostly fix cross-crate use of underscore items by inverting the "gensyms are lost in metadata" bug as described in #56303 (comment). Fix unused import warnings for single-segment imports (first commit) and `use crate_name as _` imports (as specified in #56303 (comment)). Prohibit accidentally implemented `static _: TYPE = EXPR;` (cc #55983). Add more tests for `use foo as _` imports.
☀️ Test successful - status-appveyor, status-travis |
cc @rust-lang/compiler, this is needed to backport #57160. |
I'm removing the beta-nominated tag here because this is rolled into #57483 |
Do not encode gensymed imports in metadata (Unless they are underscore `_` imports which are re-gensymed on crate loading, see rust-lang#56392.) We cannot encode gensymed imports properly in metadata and if we encode them improperly, we can get erroneous name conflicts downstream. Gensymed imports are produced by the compiler, so we control their set, and can be sure that none of them needs being encoded for use from other crates. A workaround that fixes rust-lang#59243.
Do not encode gensymed imports in metadata (Unless they are underscore `_` imports which are re-gensymed on crate loading, see rust-lang#56392.) We cannot encode gensymed imports properly in metadata and if we encode them improperly, we can get erroneous name conflicts downstream. Gensymed imports are produced by the compiler, so we control their set, and can be sure that none of them needs being encoded for use from other crates. A workaround that fixes rust-lang#59243.
So they cannot be cloned by macros. See #56303 for the discussion.
Mostly fix cross-crate use of underscore items by inverting the "gensyms are lost in metadata" bug as described in #56303 (comment).
Fix unused import warnings for single-segment imports (first commit) and
use crate_name as _
imports (as specified in #56303 (comment)).Prohibit accidentally implemented
static _: TYPE = EXPR;
(cc #55983).Add more tests for
use foo as _
imports.