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

extern_types associated functions aren't visible from other crates #46665

Closed
crumblingstatue opened this issue Dec 11, 2017 · 2 comments · Fixed by #77375
Closed

extern_types associated functions aren't visible from other crates #46665

crumblingstatue opened this issue Dec 11, 2017 · 2 comments · Fixed by #77375
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically C-bug Category: This is a bug. F-extern_types `#![feature(extern_types)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@crumblingstatue
Copy link
Contributor

crate foo:

#![feature(extern_types)]

extern "C" {
    pub type Foo;
}

impl Foo {
    pub fn new() -> FooBox {
        let raw = unimplemented!("Get through ffi");
        FooBox(raw)
    }
}

pub struct FooBox(*mut Foo);

impl Drop for FooBox {
    fn drop(&mut self) {
        unimplemented!("call ffi drop");
    }
}

crate foouser:

extern crate foo;

fn main() {
    let foo = foo::Foo::new();
    println!("{:p}", &foo);
}

Error:

error[E0599]: no function or associated item named `new` found for type `foo::Foo` in the current scope
 --> foouser.rs:4:15
  |
4 |     let foo = foo::Foo::new();
  |               ^^^^^^^^^^^^^ function or associated item not found in `foo::Foo`

This error does not occur if main is located within the same crate.

@crumblingstatue
Copy link
Contributor Author

crumblingstatue commented Dec 11, 2017

This breaks real life code: jeremyletang/rust-sfml@eb87055

It breaks the various use sites in tests, examples, etc.

And of course, it would break any user code that uses these inherent methods.

@kennytm kennytm added the C-bug Category: This is a bug. label Dec 11, 2017
@SimonSapin SimonSapin added A-resolve Area: Name/path resolution done by `rustc_resolve` specifically T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 14, 2018
@crumblingstatue crumblingstatue changed the title extern_types inherent methods do not get transferred across crate boundary extern_types associated functions aren't visible from other crates May 14, 2018
@petrochenkov
Copy link
Contributor

Fixed in #77375.

@jonas-schievink jonas-schievink added F-extern_types `#![feature(extern_types)]` requires-nightly This issue requires a nightly compiler in some way. labels Sep 30, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Oct 1, 2020
rustc_metadata: Do not forget to encode inherent impls for foreign types

So I tried to move FFI interface for LLVM from `rustc_codegen_llvm` to `rustc_llvm` and immediately encountered this fascinating issue.

Fixes rust-lang#46665.
@bors bors closed this as completed in b97334f Oct 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically C-bug Category: This is a bug. F-extern_types `#![feature(extern_types)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants