-
Notifications
You must be signed in to change notification settings - Fork 183
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
Resolve log ambiguity #518
Comments
Yes, naming the However, now is too late - every single example starts with this line early-on in If there are resolution issues within some concrete module of the Btw, glob imports ( What compile error do you see in the |
Fair enough about wanting to keep existing examples compatible. Yeah, the globs definitely don't help, but I also don't know if the benefit of As for the error I get: (The netif one only is on error[E0659]: `log` is ambiguous
--> /home/name/.cargo/git/checkouts/esp-idf-svc-a28457b0e32c6283/9e70526/src/fs/fatfs.rs:7:5
|
7 | use log::warn;
| ^^^ ambiguous name
|
= note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
= note: `log` could refer to a crate passed with `--extern`
= help: use `::log` to refer to this crate unambiguously
note: `log` could also refer to the struct imported here
--> /home/name/.cargo/git/checkouts/esp-idf-svc-a28457b0e32c6283/9e70526/src/fs/fatfs.rs:10:5
|
10 | use crate::sys::*;
| ^^^^^^^^^^^^^
= help: consider adding an explicit import of `log` to disambiguate
= help: or use `self::log` to refer to this struct unambiguously
error[E0659]: `log` is ambiguous
--> /home/tony/.cargo/git/checkouts/esp-idf-svc-a28457b0e32c6283/9e70526/src/netif.rs:963:9
|
963 | use log::debug;
| ^^^ ambiguous name
|
= note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
= note: `log` could refer to a crate passed with `--extern`
= help: use `::log` to refer to this crate unambiguously
note: `log` could also refer to the struct imported here
--> /home/name/.cargo/git/checkouts/esp-idf-svc-a28457b0e32c6283/9e70526/src/netif.rs:966:9
|
966 | use crate::sys::*;
| ^^^^^^^^^^^^^
= help: consider adding an explicit import of `log` to disambiguate
= help: or use `self::log` to refer to this struct unambiguously
For more information about this error, try `rustc --explain E0659`.
error: could not compile `esp-idf-svc` (lib) due to 2 previous errors |
What is really weird is that neither I nor the CI is seeing these errors. Do you enable some extra components in ESP IDF? Or do you have some special Trying to understand what defines the |
It looks like the
Plus I have the |
CI does run with Oh well, I think it would be easier if (once again) we search &replace Would you we willing to try it out by first addressing the compilation errors in the modules where you exhibit the problem ( BTW: I assume all of that is with |
There is the possibility of aliasing the log package to help prevent this in the future. I'd rather have a smart Clippy lint, but that requires more nightly shenanigans that I'm unfamiliar with. My main goal with this issue is wanting to prevent more devs like myself to have to open another issue/PR in a year or so when someone else forgets two colons and it slips through CI. I originally was running with this commit, but And I'm already trying it out, seems to work fine, but I'm having issues with other SPI devices/threads (you might catch me in the matrix channel 😅) so I haven't quite been able to do more than read a sub-kb |
In the meantime this is fixed with 3f2ce04 If you would like to work on a more elaborate solution, we can keep this issue open. But otherwise I would close it. |
Howdy. I've been using a lot from
esp-rs
's work recently, and I've been really impressed! The traits fromembedded-hal
let me move a device from native SPI to bitbanged SPI, and use the originalesp-idf-hal
impls as a reference, worked almost first try!.Back on topic, I wanted to mention something that's disappointed me and I think needs addressed better than it has been before.
There's a module in here named log, and there's an external dependency named log.
This leads to confusion in cases like this one:
Whenever the compiler can't fully reason out which
log
to use (::log
: the crate, orsys::log
: the module), it halts compilation and throws that up.I'm writing this now because of this happening again in fatfs.rs.
While I could just throw in a PR that uses
::log
in that file, that feels inadequate. I also don't want to alias thelog
macros in Cargo.toml withor try to rename the
log
module without consulting with y'all, so here I am.My naïve suggestion is to rename the module to perhaps
logger
, given that's how it's sometimes referred to in that small file.What do you think is the best solution?
The text was updated successfully, but these errors were encountered: