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

Permit use before import #48

Closed
graydon opened this issue Jun 22, 2010 · 0 comments
Closed

Permit use before import #48

graydon opened this issue Jun 22, 2010 · 0 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@graydon
Copy link
Contributor

graydon commented Jun 22, 2010

The parser is a little fussy at the moment and requires you to put
import/export directives before use directives. This should be relaxed.

mbrubeck pushed a commit to mbrubeck/rust that referenced this issue Oct 17, 2011
pcwalton added a commit to pcwalton/rust that referenced this issue Aug 16, 2014
public, including in trait bounds and typedefs.

There are three main patterns that this breaks. First is code that uses
private trait bounds in public APIs:

    pub mod a {
        trait Trait { ... }
        pub fn f<T:Trait>() { ... }
    }

Change that code to export the trait. For example:

    pub mod a {
        pub trait Trait { ... }     // note `pub`
        pub fn f<T:Trait>() { ... }
    }

Second, this change breaks code that was relying on
`#[allow(visible_private_types)]`. That lint is now a hard error, and
cannot be overridden. For example:

    mod helper {
        pub struct Foo { ... }
    }
    pub mod public {
        use helper::Foo;
        pub fn f() -> Foo;
    }

Because there is no way for code that uses `public::f` to name `Foo`,
this is no longer allowed. Change affected code to look like this:

    pub mod helper {    // note `pub`
        pub struct Foo { ... }
    }
    pub mod public {
        use helper::Foo;
        pub fn f() -> Foo;
    }

Third, this change breaks code that was relying on being able to
reference private typedefs in public APIs. For example:

    pub mod b {
        type Foo = int;
        pub fn f(_: Foo) { ... }
    }

Change this code to:

    pub mod b {
        pub type Foo = int; // note `pub`
        pub fn f(_: Foo) { ... }
    }

For now, the old behavior can be obtained with
`#[feature(visible_private_types)]`. However, the preciase semantics of
this feature gate may be unstable.

This implements RFC rust-lang#48.

Closes rust-lang#16463.

[breaking-change]
pcwalton added a commit to pcwalton/rust that referenced this issue Sep 23, 2014
This breaks code like:

    struct Foo {
        ...
    }

    pub fn make_foo() -> Foo {
        ...
    }

Change this code to:

    pub struct Foo {    // note `pub`
        ...
    }

    pub fn make_foo() -> Foo {
        ...
    }

The `visible_private_types` lint has been removed, since it is now an
error to attempt to expose a private type in a public API. In its place
a `#[feature(visible_private_types)]` gate has been added.

Closes rust-lang#16463.

RFC rust-lang#48.

[breaking-change]
bors added a commit that referenced this issue Sep 23, 2014
…alexcrichton

This breaks code like:

    struct Foo {
        ...
    }

    pub fn make_foo() -> Foo {
        ...
    }

Change this code to:

    pub struct Foo {    // note `pub`
        ...
    }

    pub fn make_foo() -> Foo {
        ...
    }

The `visible_private_types` lint has been removed, since it is now an
error to attempt to expose a private type in a public API.

Closes #16463.

RFC #48.

[breaking-change]

r? @alexcrichton
oli-obk pushed a commit to oli-obk/rust that referenced this issue Jul 19, 2017
change the block and stmt position after a function call returns
kazcw pushed a commit to kazcw/rust that referenced this issue Oct 23, 2018
…rrect

Add a test for x86 runtime support
dlrobertson pushed a commit to dlrobertson/rust that referenced this issue Nov 29, 2018
Added links to descriptions of XID_start and XID_continue in identifiers section.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

1 participant