Add syn_mid::ImplItemMethod

[1tgr]

For parsing impl blocks without method bodies.

Also adds syn_mid::ImplItem and syn_mid::Item, with the types other than ImplItemMethod delegated to syn.

[taiki-e]

What APIs do you actually need? ImplItemMethod (struct) + ImplItem (enum, 1 variant) + ItemImpl (struct) + Item (enum, 2 variant)?

delegated to syn

I'm not sure what this means. You need the full feature of syn to let syn parse it. Or does that mean treating anything other than a method as a variant like Item::Verbatim?

FWIW, as rustc syntactically accepts top-level functions without body, we can also change ItemFn. (aside from we want to do that or not)

[1tgr]

What APIs do you actually need? ImplItemMethod (struct) + ImplItem (enum, 1 variant) + ItemImpl (struct) + Item (enum, 2 variant)?

Yes, I think this is enough. I started an implementation within syn_mid but I got bogged down when I started copying and pasting a lot of parser code from syn. And it looks like there is some overlap between the code to parse ImplItemMethod and the existing code in syn_mid that parses ItemFn.

You need the full feature of syn to let syn parse it.

Yes, this is fine - I mean syn_mid provides ItemImplMethod (and ImplItem, ItemImpl and Item), and other variants within ImplItem are fully parsed and exposed in terms of syn's types.

ImplItemConst is the other variant within ImplItem that could contain a non-trivial body, so it could be another candidate for special handling by syn_mid, but I haven't yet encountered any large const declarations within impl blocks.

The background to this is as a speedup for crates like pyo3 that parse impl blocks but only care about function signatures. I'm hoping to improve compile times of code that uses pyo3 by replacing syn with syn_mid.

[taiki-e]

Yes, this is fine - I mean syn_mid provides ItemImplMethod (and ImplItem, ItemImpl and Item), and other variants within ImplItem are fully parsed and exposed in terms of syn's types.

I'm a bit confused about this because one of the purposes of this crate was for users who don't want to depend on the full feature of syn, but want to parse functions.

That said, if we do it under the feature flag, it might be fine.

[HKalbasi]

My use case for this crate is saving compile time and forward compatibility with rust syntax by not parsing the function bodies. So I prefer completeness of structs over compile time benefits of removing them. And I think a feature flag is fine.

[taiki-e]

Ok, I would accept PRs to implement these items under the feature flag.