Do not encode gensymed imports in metadata#59296
Merged
bors merged 1 commit intorust-lang:masterfrom Mar 24, 2019
Merged
Conversation
Contributor
|
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
estebank
reviewed
Mar 19, 2019
| ), | ||
| kind: ast::UseTreeKind::Simple( | ||
| Some(Ident::new(keywords::Underscore.name().gensymed(), new_span)), | ||
| Some(Ident::new(Name::gensym("__dummy"), new_span)), |
Contributor
There was a problem hiding this comment.
Doesn't this shift the problem to the possible existence of __dummy somewhere in the namespace?
Contributor
Author
There was a problem hiding this comment.
No, it's still a gensym, so it doesn't conflict with anything locally + it's not written into metadata since it's no longer an underscore.
(Previously it wasn't written due to the binding.vis != ty::Visibility::Invisible condition, but I removed it to simplify things a bit.)
Contributor
|
@bors r+ |
Collaborator
|
📌 Commit 30d5dc9 has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Mar 19, 2019
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.
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Mar 24, 2019
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.
bors
added a commit
that referenced
this pull request
Mar 24, 2019
Rollup of 7 pull requests Successful merges: - #59213 (Track changes to robots.txt) - #59239 (Remove inline assembly from hint::spin_loop) - #59251 (Use a valid name for graphviz graphs) - #59296 (Do not encode gensymed imports in metadata) - #59328 (Implement specialized nth_back() for Box and Windows.) - #59355 (Fix ICE with const generic param in struct) - #59377 (Correct minimum system LLVM version in tests)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(Unless they are underscore
_imports which are re-gensymed on crate loading, see #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 #59243.