Ancestors

Written by matzipan on 2025-01-13 at 23:31

I have a #rust crate which is reliably building in the stable channel releases of the last 4 months and has been reliably not building in the nightly channel release of the last 4 months. I am not enabling any unstable features.

What could be the problem?

I only arbitrarily stopped at 4 months ago to go to bed. I did not check yet how far back I can see this issue. But my understanding of the rustc release model tells me this shouldn’t happen…

=> More informations about this toot | More toots from matzipan@hachyderm.io

Toot

Written by Fabio Valentini on 2025-01-14 at 09:39

@matzipan the error message seems to come from inside the macro expansion for #[derive(lox_derive::KvnDeserialize)]

I've had vaguely similar problems in proc macros before - it's usually been due to the syn / proc-macro2 crates detecting the current Rust version in their build.rs and generating different code on nightly.

=> More informations about this toot | More toots from decathorpe@mastodon.social

Descendants

Written by matzipan on 2025-01-14 at 09:59

@decathorpe oh that’s interesting. I will expand today

=> More informations about this toot | More toots from matzipan@hachyderm.io

Written by matzipan on 2025-01-19 at 22:54

@decathorpe Yeah I can confirm that the code generation was different in slightly odd ways that I don't understand and can't fully explain. It's as if the parsing was wrong but syn was silently accepting it and proc macro was generating a /ERROR/ like this one (https://github.com/dtolnay/proc-macro2/blob/83519e88337217c75794935381de61ab02c60a9b/src/parse.rs#L166) in the code.

Then another issue was that the string returned by .span().source_text() was different on nightly than on stable. I worked around this by using the segment information directly instead of .span(). I have an MR: https://github.com/lox-space/lox/pull/191/files

With this it seems to compile on nightly.

=> More informations about this toot | More toots from matzipan@hachyderm.io

Written by Fabio Valentini on 2025-01-19 at 23:15

@matzipan yeah, proc-macros are strange and mysterious 😅

I had a similar problem once (though just because I didn't know about the syntax, not because it was broken on nightly) ...

referring to a type in the derive macro like T::do_something() is only valid if T is not generic.

This syntax works always: <T>::do_something() (expanding to, for example, <Option<U>>::do_something())

Your initial error message reminded me of this problem, though I'm not sure the cause is the same.

=> More informations about this toot | More toots from decathorpe@mastodon.social