thread_local rather than global state for context?

[andrewrch]

Hi.

An issue I have run into a few times is that when mocking an associated or global function, the context itself is global. this means that tests need to be serialized (I tend to use serialize_test) so that tests running in parallel do not modify mock state of other running tests. Would adding a context_tl where the state is stored using thread_local be an acceptable extension to the library?

[asomers]

Yes, serializing tests is what you need to do now. And unconditionally using thread-local context is not possible, because some tests are multithreaded. But an opt-in mechanism might work. Could you please give a usage example to show what you have in mind?

[smichaku]

Trying to bring this back to life... This would be really useful and remove the need for using an extra dependency and boilerplate for serialization. IMO it's also gonna make writing tests less error-prone (forgetting to serialize, or doing it wrong e.g. placement of #[serialize] and #[case] attributes with the serial_test and rstest crates).

I'm not sure about usage - perhaps a metaitem such as #[automock(global_context_storage = thread_local)]?