https://github.com/oxc-project/oxc/blob/2476dceee0a656a00d5138e0aeb34b5c062883d8/crates/oxc_span/src/atom.rs#L62-L68

https://github.com/oxc-project/oxc/blob/2476dceee0a656a00d5138e0aeb34b5c062883d8/crates/oxc_span/src/atom.rs#L76-L80

So Atom::clone_in copies the underlying string data and re-allocates it in new allocator.

This is the correct behavior when cloning from one allocator into another allocator - string data does need to be copied into the new allocator.

But when cloning within same allocator, this string copying is unnecessary. Could just do Atom::clone, which creates another reference to original underlying string data, with no data copy.

Not sure how to avoid this copying. Do we need a 2nd cloning trait for within-same-allocator cloning? And how would we enforce that the allocator provided to clone_in is the same allocator as the original? (or maybe we don't need to exactly - 'old_alloc: 'new_alloc would suffice to ensure that the string data in old allocator lives longer than the new Atom).