Ancestors

Toot

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

Descendants

Written by Ben Pfaff on 2025-01-13 at 23:39

@matzipan If X is "reliably building in the stable channel releases of the last 4 months", it appears that you're asserting "X && !X", so I'm not sure what to suggest. I guess that there is some minor mistake in what you're suggesting.

=> More informations about this toot | More toots from blp@framapiaf.org

Written by matzipan on 2025-01-14 at 07:33

@blp I suspect it too. But I am not sure what it is. I realised that I have an easy way to share the error message: https://docs.rs/crate/lox-io/0.1.0-alpha.2/builds/1591321

I’m still in the investigation phase. I think I need to dig into the expansion next.

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

Written by Zeeshan Ali Khan :rust: 🇺🇦 on 2025-01-14 at 08:45

@matzipan what @blp is pointing out is that you wrote it builds on stable and then wrote the opposite. I think you meant to write that it doesn't build on unstable/nightly?

=> More informations about this toot | More toots from zeenix@toot.cat

Written by matzipan on 2025-01-14 at 08:55

@zeenix @blp oh my god hahahahahahha. Yes. It doesn’t build nightly.

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

Written by robot 9001 on 2025-01-13 at 23:59

@matzipan you can use cargo-msrv https://github.com/foresterre/cargo-msrv to validate which Rust versions your crate can be built / "works" on as per your crate's tests (though it kinda assumes there's a minimal version from which onwards all newer ones work as well).

Since you didn't tell the build error you get, it's hard to support any further.

Is the problem with your own code or a dependency?

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

Written by dohse on 2025-01-14 at 07:27

@robo9k @matzipan now I am excited about the solution

=> More informations about this toot | More toots from dohse@chaos.social

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

@dohse @robo9k https://hachyderm.io/@matzipan/113857481046663708

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

Written by matzipan on 2025-01-14 at 07:31

@robo9k own code. It’s a very weird issue which is a bit hard to describe. It’s complaining about double colons missing for the turbo fish. So it wants Vec::<…> instead of Vec<>. But when I rustfmt, they get removed. If I don’t rustfmt it gets rid of those particular errors, but there are a bunch of others.

The issue is shown at a struct which has a proc macro applied so I will try to expand it and see if maybe there is a problem in the expansion.

I realize now that I have an easy way of sharing the error: https://docs.rs/crate/lox-io/0.1.0-alpha.2/builds/1591321

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

Written by robot 9001 on 2025-01-14 at 18:14

@matzipan from the unexpanded code this looks weird indeed, but the error is missing more context to make sense of it, like imports, opened braces etc.

It would probably help if you have the expanded code and/or a more minimal example.

Does this also happen in a new crate with a new minimal struct when you slap just that derive macro on it?

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

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

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