(answer: nasal demons of undefined behavior)
This necessarily is a question that depends on implementation details in the stdlib, since breaking the type system like this means unsafe data races and full on specified undefined behavior.
Pest’s meta parse tree is defined using Rc, since pest’s compiler does all of its work in a single thread. In pest-ast, however, we’d benefit from stuffing a meta parse tree into a global so that we can reuse that computation between proc-macro calls.
The stuffed data structure can be considered “leaked”, as none of the Rcs will be dropped in the future, and we rely on the OS to clean up. Simplifying things a bit, there is no interior/shared mutability within the structure, but working with it necessarily means cloning Rcs.
If Rcs are cloned and dropped from multiple threads, what’s the “worst” that can happen? Reference counts being higher than accurate is safe and even fine as the data is “leaked” already, but reference counts being lower than accurate would lead to freeing while Rcs still exist.
I’m thinking the only potentially safe way to do this is to have a lock that’s required to be locked when cloning or dropping an Rc (thus writing to the ref count). A lock shouldn’t be necessary for operations that just read the value and/or ref count. But I want to check that this is sound before going forward with it.
(That, and pest 3.0 may end up changing the story a lot.)