update syn&quote

[hoodie]

Hi there, this is my work in progress, I just spent the weekend getting up to speed with proc-macros at all.

Full transparency: this doesn't compile at all yet. I don't want to impose, but if you feel like pitching in, it would be much appreachiated, it is rather demanding work making this compile. 😉

[koivunej]

I haven't been able to end my end of the bargain (fixing CI etc) because of $non_project_issues but great you already got a PR. I'll try to go through it end of today.

[hoodie]

this is absolutely NOT urgent BTW
for me this is basically just the difference between being able to name a field r#type vs typ, that's it.
so no pressure please

[hoodie]

So I finally got the lib to compile. but now not all the tests compile anymore because I might have missed some cases.

[koivunej]

Looking good so far! I've migrated this project to github actions so just do a rebase on top of the latest master when you feel like it.

Also noticed that I didn't quite see how should the derive functionality work in the first place :) This currently works on a duck-typing approach (mere existence of val.into_owned() is enough), which I guess I am surprised now that it worked at all. There probably should had been a top level crate for a trait of this conversion, and implementations of it for the core/std types and so on. But we can get to that in the aftermath of this upgrade :)

[hoodie]

As far as I understand proc-macros for now you don't know much about the code other than the syntax itself. So yes, the safest thing seems to be to implement your own trait and just expect/require that all types in the fields of your struct do so too.
Also what I learned from the proc-macro-workshop: it is super fine to just panic for cases you don't want to handle, that panic message will even show up as a compile error, which is quite convenient.

[hoodie]

Merry Xmas! I kinda worked on this on and off in between some family time. Sorry about the weird format and all the dbg!() macros still, I very much intend to rebase this into something much clearer eventually.
Right now it already seems to pass all but the enum tests.

[hoodie]

Hi @koivunej. I thing I got it done.
Would be great if you could check it out.
Thanks

[koivunej]

Thank you very much!

I think this is looking good, you know more than I do at this point. One question so far popped in to mind while trying to understand the diffs. Thanks for keeping my type_hopefully_is vagueness :)

As the tests pass I'm inclined to just merge this straight away. You were interested in adding the support for raw identifiers so please go ahead. If you had some parts where you were looking for my input specifically, we can revisit this PR even after merging.

[koivunej]

The previous way for ident generation was x{index} ... The a..=z is probably enough for everyone, just wondering if you picked this up from some material as a suggested way to generate identifiers? I wasn't able to find google this up.

[hoodie]

oh that's a good idea actually, I was a bit in creative mood at that moment, but x{index} or possibly arg_{index} are actually more reasonable, will do that

[hoodie]

In case you‘re waiting on anything regrading raw identifiers, there is nothing left to do. They come for free with the update.

[koivunej]

All right, thanks again @hoodie. I'll merge this and close my hoodie#1, maybe add back that test case and do a bit of fumbling around releasing.

[hoodie]

Thanks @koivunej, sorry about hoodie#1, I hadn't seen that issue yet