Upgrade syn to 2.0

[jplatte]

No description provided.

[badboy]

With this we would now have both 1.0 and 2.0 as deps here.
m-c is still (obviously) vendoring 1.0. Going to 2.0 here means we will also duplicate everything over there. Unless there are good reasons to just jump ahead I'd prefer if we're not the first doing that.

[jplatte]

I think having both 1.0 and 2.0 in the tree will soon be unavoidable. dtolnay already upgraded his own (big) crates like thiserror and serde_derive.

But it's not critical to have this merged soon.

[badboy]

I think having both 1.0 and 2.0 in the tree will soon be unavoidable. dtolnay already upgraded his own (big) crates like thiserror and serde_derive.

But it's not critical to have this merged soon.

yeah, we will have to figure this out over on the m-c side eventually.

[jplatte]

Has this been figured out on the m-c side? Attribute parsing is a bit more convenient in syn 2.0, so it would be nice to have that new API when working on the proc-macro frontend.

edit: Judging by this being the only syn package in m-c's Cargo.lock, nothing has changed.

[badboy]

Has this been figured out on the m-c side? Attribute parsing is a bit more convenient in syn 2.0, so it would be nice to have that new API when working on the proc-macro frontend.

edit: Judging by this being the only syn package in m-c's Cargo.lock, nothing has changed.

I'll make myself a todo to find some people to figure this out next week.

[badboy]

I got the OK to land syn v2 in m-c as well, so we can now land this. I'll work on a followup to upgrade askama and some others as well to reduce the number of crates on syn v1

[badboy]

@jplatte looks like this has some merge conflicts (but GitHub is acting up and not even letting me do the usual resolving in the UI?). Can you rebase this PR?