-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
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. |
This broke semver's CI as well. |
I had mistook this for a different issue, this one does look like one that we can address |
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.
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
Following the tutorial here I keep getting |
@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. |
@Deedasmi Ah ok, thanks. I'll ignore for now |
@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) |
Here is a good way to mute the warning on a per-file basis: #![allow(proc_macro_derive_resolution_fallback)] |
Now that 1.29 is out is there a plan to cut a release for this fix? |
I'm also wondering when this is going to get released. Hit it just now as well. |
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. |
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. |
You can silence specifically this error with |
temporary until (likely) diesel 1.4: diesel-rs/diesel#1785
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
This is temporary workaround. See <diesel-rs/diesel#1785 (comment)>.
This is temporary workaround. See <diesel-rs/diesel#1785 (comment)>.
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.. |
I know this is a closed issue but I still get this warning after addding |
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. |
Setup
Versions
Feature Flags
Problem Description
I got a lot of warns after rustup and cargo update, like follow:
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
The text was updated successfully, but these errors were encountered: