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 · 13 comments

Comments

Projects
None yet
9 participants
@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

This comment has been minimized.

Member

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

This comment has been minimized.

steveklabnik commented Jul 16, 2018

This broke semver's CI as well.

@sgrif sgrif reopened this Jul 17, 2018

@sgrif

This comment has been minimized.

Member

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

Future proof us against upcoming changes to derives
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

rust version: update to nightly-2018-07-18
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

This comment has been minimized.

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

WillSquire commented Aug 1, 2018

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

@apiraino

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

gmjosack commented Sep 16, 2018

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

@vmalloc

This comment has been minimized.

Contributor

vmalloc commented Sep 16, 2018

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

@sgrif

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

Member

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

chore: quiet diesel warnings under rust 1.29
temporary until (likely) diesel 1.4:
diesel-rs/diesel#1785

pjenvey added a commit to mozilla-services/syncstorage-rs that referenced this issue Sep 19, 2018

chore: quiet diesel warnings under rust 1.29
temporary until (likely) diesel 1.4:
diesel-rs/diesel#1785

alatiera added a commit to alatiera/hammond that referenced this issue Sep 22, 2018

Fix rustc warnings
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

arkhe634 added a commit to pbl-2018-hillclimb/burning-pro-server that referenced this issue Oct 26, 2018

@asonix asonix referenced this issue Nov 3, 2018

Merged

Add Actix #156

pkgw added a commit to pkgw/drorg that referenced this issue Dec 5, 2018

@jimmycuadra jimmycuadra referenced this issue Dec 8, 2018

Closed

Compatibility with use_extern_macros #1933

2 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment