Resolving #27 entailed walking on some razor blades to figure out the right set of lifetime constraints needed to allow deserializing references, without allowing invalid deserializations (like deserializing a fake &'static T from stack-allocated data).
Given that someone (maybe you, maybe I) may need to touch that code again in the future, and that it is easy to get wrong, I would sleep better at night if I could add some compilation failure tests to #28 in order to make sure that some classic invalid reference deserialization examples will continue to refuse to compile in the future.
Unfortunately, rust does not have a nice built-in mechanism for that sort of tests, but someone has suggested using the trybuild crate for this purpose.
The two drawbacks are that 1/it's one more dependency and 2/since it's based on parsing rustc output, which is not subjected to any stability guarantee, those tests are likely to require occasional maintenance the future so that they keep working on new rustc versions.
Resolving #27 entailed walking on some razor blades to figure out the right set of lifetime constraints needed to allow deserializing references, without allowing invalid deserializations (like deserializing a fake
&'static Tfrom stack-allocated data).Given that someone (maybe you, maybe I) may need to touch that code again in the future, and that it is easy to get wrong, I would sleep better at night if I could add some compilation failure tests to #28 in order to make sure that some classic invalid reference deserialization examples will continue to refuse to compile in the future.
Unfortunately, rust does not have a nice built-in mechanism for that sort of tests, but someone has suggested using the trybuild crate for this purpose.
The two drawbacks are that 1/it's one more dependency and 2/since it's based on parsing rustc output, which is not subjected to any stability guarantee, those tests are likely to require occasional maintenance the future so that they keep working on new rustc versions.