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

Can't implement methods for an imported struct type without using global path #11798

Closed
nham opened this issue Jan 25, 2014 · 4 comments
Closed

Comments

@nham
Copy link
Contributor

nham commented Jan 25, 2014

This does not work:

use foo::Bar;

fn main() {
    impl Bar {
        fn boop(&self) -> bool {
            true
        }
    }

    let y = Bar {y: 8};
    println!("{}", y.boop());
}

mod foo {
    pub struct Bar {
        y: int,
    }
}

It results in:

module_name_used_type.rs:10:13: 10:16 error: `Bar` does not name a structure
module_name_used_type.rs:10     let y = Bar {y: 8};
                                        ^~~

Changing "impl Bar" to "impl ::foo::Bar" on line 3 does work, however. Is this the intended behavior?

@nham
Copy link
Contributor Author

nham commented Apr 6, 2014

This appears to be a problem still. With the latest Rust master, the following compiles and runs without error:

use foo::Bar;

fn main() {
    let b = Bar {y: 8};
    println!("{}", b.y);
}

mod foo {
    pub struct Bar {
        pub y: int,
    }
}

But this does not:

use foo::Bar;

fn main() {
    impl Bar {
        fn boop(&self) -> bool {
            true
        }
    }

    let b = Bar {y: 8};
    println!("{}", b.y);
}

mod foo {
    pub struct Bar {
        pub y: int,
    }
}

The above fails to compile with this error:

implimp.rs:10:17: 10:20 error: `Bar` does not name a structure
implimp.rs:10         let b = Bar {y: 8};
                              ^~~

Changing "impl Bar" to "impl ::foo::Bar" still fixes it.

@nham
Copy link
Contributor Author

nham commented May 12, 2014

I believe this is the same as #9052

@steveklabnik
Copy link
Member

This now has a real error message:

hello.rs:4:10: 4:13 error: inherent implementations are not allowed for types not defined in the current module
hello.rs:4     impl Bar {
                    ^~~
error: aborting due to previous error

@steveklabnik
Copy link
Member

And yes, as the error says, this is expected.

flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 16, 2023
move `suspicious_doc_comments` to doc pass

This was my first lint. I've been meaning to move it over to `doc.rs` since that's a better place.
There weren't any changes made to the lint logic itself.

I guess this can be considered part of rust-lang#11493

changelog: none
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 1, 2023
Split `doc.rs` up into a subdirectory

So, first, sorry for the bad diff. 😅

In rust-lang#11798, `@flip1995`  suggested splitting `doc.rs` up, much like how we have the `methods/`, `matches/`, `types/` subdirectories.
I agree with this, the file is getting bigger as we add more and more doc lints that it makes sense to do this refactoring.

This is purely an internal change that moves things around a bit.
(**EDIT:** depending on the outcome of rust-lang/rust-clippy#11801 (comment) , this may change the lint group name from `doc_markdoc` to `doc`).

I tried to not change any of the actual logic of the lints and as such some things weren't as easy to move to a separate file. So we still have some `span_lint*` calls in the `doc/mod.rs` file, which I think is fine. This is also the case in `methods/mod.rs`.

Also worth mentioning that the lints missing_errors_doc, missing_panics_doc, missing_safety_doc and unnecessary_safety_doc have a lot of the same logic so it didn't make much sense for each of these to be in their own file. Instead I just put them all in `missing_headers.rs`

I also added a bit of documentation to the involved `check_{attrs,doc}` methods.

changelog: none
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

No branches or pull requests

2 participants