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

Warn or error on multiple-mod code duplication #5765

Closed
Kimundi opened this issue Apr 7, 2013 · 5 comments
Closed

Warn or error on multiple-mod code duplication #5765

Kimundi opened this issue Apr 7, 2013 · 5 comments
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. A-resolve Area: Name/path resolution done by `rustc_resolve` specifically

Comments

@Kimundi
Copy link
Member

Kimundi commented Apr 7, 2013

Sometimes people use multiple mod statements that refer to the same file in order to access that files content as a module in different modules/files, thinking all those instances would be identical. But in reality that just duplicates all definitions in the file at different places in the module hierarchy, which leads to confusing errors like two presumably identical types not being identical etc.

I think two mod statements in a crate that refer to the same file should at least emit a code duplication warning, if not an error, because it's almost never what you want.

@emberian
Copy link
Member

emberian commented Jul 5, 2013

@Kimundi testcase please?

@Kimundi
Copy link
Member Author

Kimundi commented Jul 6, 2013

Well the problem is basically if you have written your source files like this:

crate.rs:

pub mod a;
pub mod b;

a.rs:

pub mod c;

b.rs:

pub mod c;

c.rs:

pub struct Foo;

A beginner not familiar with the module system might now think that a::c::Foo and b::c::Foo are aliases of each other because they refer to the same file, while in fact they are two distinct copies in your module hierarchy. Seeing how you almost never want this kind of module duplication to begin with, emitting at least a warning seems to be the right thing to do.

@huonw
Copy link
Member

huonw commented Sep 23, 2013

Triage: still occurs, having a lint would be useful.

@flaper87
Copy link
Contributor

Triage: this is still an issue. I believe this will caught as part of the new resolve algorithm. ( #13449 )

@alexcrichton
Copy link
Member

flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 11, 2020
manual_async_fn: take input lifetimes into account

The anonymous future returned from an `async fn` captures all input
lifetimes. This was not being taken into account.

See https://github.com/rust-lang/rfcs/blob/master/text/2394-async_await.md#lifetime-capture-in-the-anonymous-future

changelog: Take input lifetimes into account in [`manual_async_fn`].

Fixes rust-lang#5765
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. A-resolve Area: Name/path resolution done by `rustc_resolve` specifically
Projects
None yet
Development

No branches or pull requests

5 participants