Bump proc-macro-hack to 0.5.18

[Aaron1011]

Your crate currently depends on an older version of proc-macro-hack
which is buggy, and will stop compiling in a future release of Rust.
See rust-lang/rust#74616 for more details.

[moritzheiber]

@Aaron1011 I'm not depending on proc-macro-hack directly, but rather it's a transitive dependency. Shouldn't the dependencies rather bump their version constraints instead of me "manually" adjusting Cargo.lock?

(PS: Thank you for making the effort!)

[Aaron1011]

@moritzheiber: The crates which directly depend on proc-macro-hack are all libraries, so they don't have a Cargo.lock committed. They could make a new release which just bumped the version of proc-macro-hack in use, but this would have no effect on their own CI (which will already be using the latest version).

This is a somewhat odd situation, since the library itself doesn't actually need a newer version of proc-macro-hack - it's that the overall dependency graph shouldn't contain an older version of proc-macro-hack. Normally, a version bump is for the benefit of downstream crates, but here's it's just to make sure that we don't try to compile a crate (older version of proc-macro-hack) that will eventually stop building with a newer compiler.

I've chosen to send pull requests to only 'leaf' crates (those with a Cargo.lock) to minimize the number of total crates that need to change. If I updated the Cargo.tomls in library crates that directly pull in proc-macro-hack, downstream crates (like crowbar) would still need to update their Cargo.lock files. However, several other crates would either need to make a contentless point release (just updating the Cargo.toml), or wait for enough content for a meaningful point release.

Let me know if you have any other questions. Thanks for your help in getting the ecosystem updated!

[moritzheiber]

@Aaron1011 Oh, that makes sense, I wasn't aware of the convention to not pin library dependencies. Interesting.

Thanks for your PR then!