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

Existential type complains about private type in public interface if concrete type is not pub #53546

Closed
Arnavion opened this issue Aug 20, 2018 · 9 comments

Comments

@Arnavion
Copy link

@Arnavion Arnavion commented Aug 20, 2018

#![feature(existential_type)]

pub mod foo {
    pub existential type Foo: ::std::fmt::Debug;
    pub fn foo() -> Foo {
        S
    }

    #[derive(Debug)] struct S;
}

gives

warning: private type `foo::S` in public interface (error E0446)
 --> src/lib.rs:4:5
  |
4 |     pub existential type Foo: ::std::fmt::Debug;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(private_in_public)] on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #34537 <https://github.com/rust-lang/rust/issues/34537>

Returning impl ::std::fmt::Debug does not have this restriction.

@jonhoo
Copy link
Contributor

@jonhoo jonhoo commented Jan 10, 2019

This also happens with closures:

#![feature(existential_type)]
pub existential type X: FnOnce();
pub fn foo() -> X {
    || ()
}

gives

warning: private type `[closure@src/lib.rs:5:5: 5:10]` in public interface (error E0446)
 --> src/lib.rs:3:1
  |
3 | pub existential type X: FnOnce();
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(private_in_public)] on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #34537 <https://github.com/rust-lang/rust/issues/34537>

    Finished dev [unoptimized + debuginfo] target(s) in 0.36s

And as far as I can tell, there isn't a way to work around this?

@jonhoo
Copy link
Contributor

@jonhoo jonhoo commented Jan 10, 2019

This should probably be tagged T-compiler, A-impl-trait, and A-lint.

@petrochenkov petrochenkov self-assigned this Jan 10, 2019
@petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Jan 10, 2019

I'll look what happens.
The underlying type should not be revealed during privacy checking of impl Trait types.

@jonhoo
Copy link
Contributor

@jonhoo jonhoo commented Jan 10, 2019

For some weird reason, I'm getting a hard error instead of a warning for this when it's happening in a much larger crate of mine on nightly-2019-01-09. I'm not using deny(private_in_public). Not sure whether that's related:

error[E0446]: private type `[closure@noria/src/table.rs:295:31: 295:44]` in public interface
   --> noria/src/table.rs:219:5
    |
219 |     existential type Future: Future<Item = Tagged<()>, Error = TableError>;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't leak private type
...
295 |                     .fold((), |_, _| Ok(()))
    |                               ------------- `[closure@noria/src/table.rs:295:31: 295:44]` declared as private
@jonhoo
Copy link
Contributor

@jonhoo jonhoo commented Jan 11, 2019

Ouch, when this is an error, it's really hard to work around. @petrochenkov any luck trying to figure out the cause of this?

jonhoo added a commit to mit-pdos/noria that referenced this issue Jan 11, 2019
Sadly the bug also manifests itself in netsoup, which is really hard to
work around, so we're kind of stuck here for now... Unless we Box
everything.
@petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Jan 12, 2019

Fixed in #57556

@petrochenkov petrochenkov removed their assignment Jan 12, 2019
Centril added a commit to Centril/rust that referenced this issue Jan 14, 2019
privacy: Fix private-in-public check for existential types

Fixes rust-lang#53546 (regression from rust-lang#56878)

r? @arielb1
Centril added a commit to Centril/rust that referenced this issue Jan 14, 2019
privacy: Fix private-in-public check for existential types

Fixes rust-lang#53546 (regression from rust-lang#56878)

r? @arielb1
Centril added a commit to Centril/rust that referenced this issue Jan 14, 2019
privacy: Fix private-in-public check for existential types

Fixes rust-lang#53546 (regression from rust-lang#56878)

r? @arielb1
Centril added a commit to Centril/rust that referenced this issue Jan 14, 2019
privacy: Fix private-in-public check for existential types

Fixes rust-lang#53546 (regression from rust-lang#56878)

r? @arielb1
Centril added a commit to Centril/rust that referenced this issue Jan 14, 2019
privacy: Fix private-in-public check for existential types

Fixes rust-lang#53546 (regression from rust-lang#56878)

r? @arielb1
@bors bors closed this in #57556 Jan 14, 2019
@zroug
Copy link

@zroug zroug commented Jan 15, 2019

I still get the warning for this example:

#![feature(existential_type)]

pub trait Test {
    type Foo;
    fn foo() -> Self::Foo;
}

struct FooImpl;

impl Test for () {
    existential type Foo: ;
    fn foo() -> Self::Foo {
        FooImpl
    }
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=944fd033d23b9698f766485ec9e452c8

@petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Jan 15, 2019

Reopening to investigate #53546 (comment)

@petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Jan 15, 2019

#53546 (comment) is fixed in #57649

Centril added a commit to Centril/rust that referenced this issue Jan 18, 2019
privacy: Account for associated existential types

Turns out they *can* be associated (but only in impls, not traits).
Fixes rust-lang#53546 (comment)

r? @arielb1
Centril added a commit to Centril/rust that referenced this issue Jan 19, 2019
privacy: Account for associated existential types

Turns out they *can* be associated (but only in impls, not traits).
Fixes rust-lang#53546 (comment)

r? @arielb1
@bors bors closed this in #57649 Jan 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants