Consider using an RcVec type that collocates reference count with vector elements

[dtolnay]

As of #335, TokenStream is Rc<Vec<TokenTree>>. This makes twice as many allocations as it should, because there's one that holds {strong count, weak count, data ptr, length, capacity} and a different one that holds the vector elements.

Let's look into putting these all into one allocation (except omit weak count, which we do not use) and see how it affects cargo bench --bench file --features full,parsing,test in syn.

[eddyb]

I believe such an RcVec would be roughly Rc<Thin<(len: usize, [MaybeUninit<T>])>> (or Rc<Thin<UnsizedVec<T>>> where UnsizedVec has both len and capacity as metadata).
A bit sad that we don't have the language tools to build something like that directly, but nonetheless, the functionality would be useful.

Also, I'm not 100% sure it's exactly the same, but I've been describing Lean4's Array T as being halfway between Rc<[T]> and Rc<Vec<T>>, with the intuition that it's RcVec<T>.
(For some context, Lean4 replaced GC with RC + auto-injecting Rc::make_mut, and not only does that make it faster than existing FP GC runtimes for functional data structures, it can ditch lists for flat arrays, as e.g. repeated RcVec::make_mut(xs).push(x) will only copy at most once).