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

Closing assorted resolve bugs #13409

Closed
wants to merge 3 commits into from

Conversation

alexcrichton
Copy link
Member

The commits have all the details.

Resolve is currently erroneously allowing imports through private `use`
statements in some circumstances, even across module boundaries. For example,
this code compiles successfully today:

    use std::c_str;
    mod test {
        use c_str::CString;
    }

This should not be allowed because it was explicitly decided that private `use`
statements are purely bringing local names into scope, they are not
participating further in name resolution.

As a consequence of this patch, this code, while valid today, is now invalid:

    mod test {
        use std::c_str;

        unsafe fn foo() {
            ::test::c_str::CString::new(0 as *u8, false);
        }
    }

While plausibly acceptable, I found it to be more consistent if private imports
were only considered candidates to resolve the first component in a path, and no
others.

Closes rust-lang#12612
Previously resolve was checking the "import resolution" for whether an import
had succeeded or not, but this was the same structure filled in by a previous
import if a name is shadowed. Instead, this alters resolve to consult the local
resolve state (as opposed to the shared one) to test whether an import succeeded
or not.

Closes rust-lang#13404
Previously, a private use statement would shadow a public use statement, all of
a sudden publicly exporting the privately used item. The correct behavior here
is to only shadow the use for the module in question, but for now it just
reverts the entire name to private so the pub use doesn't have much effect.

The behavior isn't exactly what we want, but this no longer has backwards
compatibility hazards.
@bors bors closed this in 0156af1 Apr 11, 2014
@alexcrichton alexcrichton deleted the resolve-fixes branch April 11, 2014 04:39
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 24, 2024
Fix `if_then_some_else_none` sugg missing closure intro

Fixes rust-lang#13407

rust-lang#13407 works in current stable. The suggestion-generating code got trampled over in 0532104 :-)

changelog: [`if_then_some_else_none`]: Fix missing closure in suggestion
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant