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

names from parent modules are not accessible without an explicit import #1785

Closed
llxxbb opened this issue Jul 15, 2018 · 16 comments
Closed

names from parent modules are not accessible without an explicit import #1785

llxxbb opened this issue Jul 15, 2018 · 16 comments

Comments

@llxxbb
Copy link

@llxxbb llxxbb commented Jul 15, 2018

Setup

Versions

  • Rust:1.29.0-nightly (254f8796b 2018-07-13)
  • Diesel:1.3.2
  • Database:sqlite
  • Operating System:win10

Feature Flags

  • diesel:

Problem Description

I got a lot of warns after rustup and cargo update, like follow:

warning: cannot find type `ThingDefine` in this scope
  --> src\data\thing\mod.rs:71:41
   |
71 | #[derive(Serialize, Deserialize, Debug, Queryable, Clone, PartialOrd, PartialEq)]
   |                                         ^^^^^^^^^ names from parent modules are not accessible without an explicit import
   |
   = note: #[warn(proc_macro_derive_resolution_fallback)] 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 #50504 <https://github.com/rust-lang/rust/issues/50504>

warning: cannot find type `NaiveDateTime` in this scope
  --> src\data\thing\mod.rs:71:41
   |
71 | #[derive(Serialize, Deserialize, Debug, Queryable, Clone, PartialOrd, PartialEq)]
   |                                         ^^^^^^^^^ names from parent modules are not accessible without an explicit import
   |
   = 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 #50504 <https://github.com/rust-lang/rust/issues/50504>

What are you trying to accomplish?

I try to add #[allow(proc_macro_derive_resolution_fallback)] on the structure used for query to disable the errors, but the warning exists yet.

What is the expected output?

I want to remove these warnings

@sgrif
Copy link
Member

@sgrif sgrif commented Jul 15, 2018

Thanks, but we don't accept errors that are specific to nightly versions of Rust. There's an ongoing discussion about this and it's not clear what the final direction will be, Diesel will not be acting on it until it's clear what we actually will need to do for stable.

@sgrif sgrif closed this Jul 15, 2018
@steveklabnik
Copy link

@steveklabnik steveklabnik commented Jul 16, 2018

This broke semver's CI as well.

@sgrif sgrif reopened this Jul 17, 2018
@sgrif
Copy link
Member

@sgrif sgrif commented Jul 17, 2018

I had mistook this for a different issue, this one does look like one that we can address

sgrif added a commit that referenced this issue Jul 17, 2018
Macro hygiene used to ignore module scope, which meant that we could
reference a type from outside our wrapper module even if we didn't
import it. That is changing in an upcoming version of Rust.

Unfortunately, we can't just do either of the recommended solutions
(either adding `use super::*` or changing to use a function instead of a
module). `use super::*` doesn't work for types defined inside of a
function, and changing ot use a function instead of a module broke our
workaround to pretend we had `$crate` when we really didn't.

With this change, an item named `diesel` must be present at the crate
root. In the case of Diesel itself, this is just a module, but for all
users they will now have to put `extern crate diesel` at the crate root.
It's unlikely folks were renaming it, but we will no longer work if they
do (the import was already located at the crate root, since you cant do
`#[macro_use] extern crate` anywhere else).

Fixes #1785.
@sgrif sgrif closed this in #1787 Jul 18, 2018
barzamin added a commit to rustodon/rustodon that referenced this issue Jul 20, 2018
note that the database crate produces a large number of warnings.
this is due to diesel-rs/diesel#1785, which has been fixed;
those changes will land in an upcoming Diesel version
@WillSquire
Copy link

@WillSquire WillSquire commented Jul 28, 2018

Following the tutorial here I keep getting names from parent modules are not accessible without an explicit import for Queryable and Insertable too, but #[macro_use] extern crate diesel; is present in main.rs? Am I missing something? Did read the merge report and tried changing to extern crate diesel; but unsure if this is correct as I got a bunch of other errors?

@Deedasmi
Copy link
Contributor

@Deedasmi Deedasmi commented Jul 31, 2018

@WillSquire This error is due to a change in the rust compiler. You can't fix it directly, as its a warning that diesel would break in the future. I think it's fixed on the repo, just not released yet.

@WillSquire
Copy link

@WillSquire WillSquire commented Aug 1, 2018

@Deedasmi Ah ok, thanks. I'll ignore for now

@apiraino
Copy link

@apiraino apiraino commented Aug 9, 2018

@WillSquire you may want to mute that warning. No big deal, AFAICS.

Shows up also with latest Rust nightly (1.30.0 as I write)

@xpe
Copy link

@xpe xpe commented Sep 9, 2018

Here is a good way to mute the warning on a per-file basis:

#![allow(proc_macro_derive_resolution_fallback)]
@gmjosack
Copy link

@gmjosack gmjosack commented Sep 16, 2018

Now that 1.29 is out is there a plan to cut a release for this fix?

@vmalloc
Copy link
Contributor

@vmalloc vmalloc commented Sep 16, 2018

I'm also wondering when this is going to get released. Hit it just now as well.

@sgrif
Copy link
Member

@sgrif sgrif commented Sep 18, 2018

The fix may be included in 1.4, which will be released in the next week or two -- But that's only assuming rust-lang/rust#52545 is fixed. If our docs still fail to build, I'll be reverting the fix before releasing 1.4.

This is a warning, not an error -- and one that you can easily silence, so it's not something we're going to cut a release over.

@gmjosack
Copy link

@gmjosack gmjosack commented Sep 18, 2018

I appreciate the update. We tend to have warnings as errors in our CI. I have this silenced for now but doing a blanket silence is problematic as it could mask other issues that crop up which is why I'd like resolution here.

Thanks again for the update and context.

@sgrif
Copy link
Member

@sgrif sgrif commented Sep 18, 2018

You can silence specifically this error with #![allow(proc_macro_derive_resolution_fallback)]. Unless you're writing a ton of custom derives, it's unlikely you'll be getting new instances of this warning.

pjenvey added a commit to mozilla-services/syncstorage-rs that referenced this issue Sep 19, 2018
temporary until (likely) diesel 1.4:
diesel-rs/diesel#1785
alatiera added a commit to alatiera/gnome-podcasts that referenced this issue Sep 22, 2018
New warnings were introduced with rustc 1.29.0

podcasts-data/src/lib.rs: this one can be removed once diesel is
upgraded.
diesel-rs/diesel#1785 (comment)

podcasts-gtk/src/i18n.rs: This is just a deprication warning
rychipman added a commit to rychipman/snake that referenced this issue Oct 4, 2018
barzamin added a commit to rustodon/rustodon that referenced this issue Oct 25, 2018
lo48576 added a commit to pbl-2018-hillclimb/burning-pro-server that referenced this issue Oct 26, 2018
This is temporary workaround.
See <diesel-rs/diesel#1785 (comment)>.
@kushwahashiv
Copy link

@kushwahashiv kushwahashiv commented Jan 14, 2019

rust is so unstable. I must consider not to move my tech stack to it and I should postpone for at least a year or so..

@GopherJ
Copy link

@GopherJ GopherJ commented Mar 14, 2019

I know this is a closed issue but I still get this warning after addding #[allow(proc_macro_derive_resolution_fallback)] in src/schema.rs and models.

@Deedasmi
Copy link
Contributor

@Deedasmi Deedasmi commented Mar 14, 2019

Just ‘#[allow’ or ‘#![allow’? They do different things (this definition vs module level)

Also, I think this was also fixed on 1.4? Could be wrong.

jslupicki added a commit to jslupicki/solteq-demo-app that referenced this issue Apr 6, 2019
jslupicki added a commit to jslupicki/rust-backend that referenced this issue Jun 6, 2020
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