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

Transitioning a 3rd party crate (conrod) to 2018 edition #56029

Closed
ghost opened this issue Nov 17, 2018 · 6 comments
Closed

Transitioning a 3rd party crate (conrod) to 2018 edition #56029

ghost opened this issue Nov 17, 2018 · 6 comments

Comments

@ghost
Copy link

ghost commented Nov 17, 2018

Hello!

I am trying to migrate https://github.com/PistonDevelopers/conrod to 2018 edition.

https://rust-lang-nursery.github.io/edition-guide/editions/transitioning-an-existing-project-to-a-new-edition.html states that:

It's our intention that the migration to new editions is as smooth an experience as possible. If it's difficult for you to upgrade to Rust 2018, we consider that a bug. If you run into problems with this process, please file a bug. Thank you!

So, here I am, although this may very well be a layer 8 problem.

What I did: I checked out conrod and first migrated conrod_derive via

cargo fix --edition

But it turned out to be quite tedious until I found out about:

cargo fix --prepare-for 2018 (any reason this is not more prominently mentioned in the guide?)

Then all the low hanging fruits were done automagically - great! (My compliments/gratitude here!)

I then proceeded enabling edition = 2018 in the Cargo.toml file and then the nightmare started:

error[E0412]: cannot find type Theme in the crate root
--> src/widget/toggle.rs:38:50
|
38 | #[derive(Copy, Clone, Debug, Default, PartialEq, WidgetStyle_)]
| ^^^^^^^^^^^^ not found in the crate root
help: possible candidate is found in another module, you can import it into scope
|
3 | use crate::theme::Theme;

Appears a few dozen times for different files! (and if it's not WidgetStyle_ then it's the WidgetCommon_ macro)

use crate::theme::Theme; does not help at all, sadly.

When I try to use use conrod_derive::WidgetStyle_ nothing changes.

When I use: use conrod_derive::style::WidgetStyle_; I get a lot more errors, now saying:

error[E0658]: The attribute conrod is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
--> src/widget/toggle.rs:49:5
|
49 | #[conrod(default = "theme.border_color")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: add #![feature(custom_attribute)] to the crate attributes to enable

if I follow that hint, I get the same errors as before adding the crate attribute with the addition of

error[E0432]: unresolved import conrod_derive::style
--> src/widget/toggle.rs:18:20
|
18 | use conrod_derive::style::WidgetStyle_;
| ^^^^^ Could not find style in conrod_derive

because style is not public... but I made it public already and the same error is still present.

Here is where I give up and let someone smarter than me point me in the right direction, because obviously I am doing something wrong.

Sorry for bothering the bugtracker with what is probably my fault and mine alone, but it was suggested and I am kind of desperate to understand this now (how else can I improve?)

@jebrosen
Copy link
Contributor

jebrosen commented Nov 17, 2018

I only took a cursory glance, but I think I can explain this. Conrod's _-suffixed macros are for use within conrod itself, where "extern crate conrod"; can't be used. At https://github.com/PistonDevelopers/conrod/blob/master/conrod_derive/src/style.rs#L28 , the "path to conrod itself" is set to "None", so #crate_tokens::Theme becomes ::Theme at https://github.com/PistonDevelopers/conrod/blob/master/conrod_derive/src/style.rs#L62 . This is probably wrong for the 2018 edition and should be something like crate::Theme instead, and the same for other similar macros.

use conrod_derive::style::WidgetStyle_; looks wrong, it should be conrod_derive::WidgetStyle_. Alternatively, #[macro_use] extern crate conrod_derive; already imports WidgetStyle_ for use from anywhere within conrod.

Unfortunately, errors in proc_macro-generated code often don't point to anything useful in the original source.

@petrochenkov
Copy link
Contributor

so #crate_tokens::Theme becomes ::Theme

Then it looks like unimplemented edition hygiene for absolute paths (including imports) - #50999.

If macro defined by 2015 edition crate produces path ::foo, then it's supposed to be interpreted according to 2015 edition rules (i.e. crate-relative).

@jebrosen
Copy link
Contributor

I then proceeded enabling edition = 2018 in the Cargo.toml file and then the nightmare started:

The macro is defined by the 2018 edition, so the 2018 import rules should apply.

@ehuss
Copy link
Contributor

ehuss commented Nov 17, 2018

cargo fix --prepare-for 2018 (any reason this is not more prominently mentioned in the guide?)

This is functionally identical to cargo fix --edition, there should be no difference.

@ghost
Copy link
Author

ghost commented Nov 18, 2018

Hm, so anyone knows how to fix this? I tried changing the let crate_tokens= expression but to no avail.
e.g. let crate_tokens = Some(syn::Ident::new("crate", proc_macro2::Span::call_site()));

I also tried some other tricks (like matching on the crate_tokens: Option<syn::Ident>), but nothing worked.

nevermind, the matching worked, I just wonder what's the right solution to get a ident for "crate"

it's like a box of worms. Whatever I fix, there is still something else to fix. I am hereby giving up.

@rylev
Copy link
Member

rylev commented Jan 15, 2021

Closing as this doesn't seem to be a specific issue.

@rylev rylev closed this as completed Jan 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants