Ideally we should have our own types, that are a bit more abstract than what syn currently provides. For instance, we don't need to keep the fn token when storing a function signature. Similarly, we don't need the :: when storing an item path.
One of the greatest benefits is that we could do some simple operations during the conversion. A simple example is trait bounds. cargo-breaking currently treats the change T: Send + Sync to T: Sync + Send as a breaking change. As a fix, we could alphabetically sort the bounds when converting data to our own types.
This issue lists what needs to be implemented to fit these goals:
[ ] #4,
[ ] #5,
[ ] representation of trait items (consts, methods and types),
[ ] reworking import representation, if needed.
This list is not exhaustive, some items may be added in the future.
Ideally we should have our own types, that are a bit more abstract than what
syn
currently provides. For instance, we don't need to keep thefn
token when storing a function signature. Similarly, we don't need the::
when storing an item path.One of the greatest benefits is that we could do some simple operations during the conversion. A simple example is trait bounds.
cargo-breaking
currently treats the changeT: Send + Sync
toT: Sync + Send
as a breaking change. As a fix, we could alphabetically sort the bounds when converting data to our own types.This issue lists what needs to be implemented to fit these goals:
This list is not exhaustive, some items may be added in the future.