Prevent future memory leaks

[overlookmotel]

We could prevent the possibility of any future memory leaks by:

• Introduce a trait Arena.
• Implement it for:
  • all primitive types which do not own external allocations - u32, &str etc.
  • oxc_allocator's Box, Vec and String.
• Create a derive macro for the trait which requires all struct fields / enum variants to also be Arena (same as a type can only be Clone if all its constituent parts are also Clone).
• #[derive(Arena)] on all AST types.
• Add a bound to Allocator::alloc<T: Arena>.

The compiler will then make it impossible to add any type which owns data external to the arena to the AST, or allocate one in the arena.

[Boshen]

Detect Memory Leak

I think we should throw more tools at it, for example

• run miri on the entire test suite
• run other memory detection tools on oxlint

[overlookmotel]

Miri is great, but insanely slow. I ran the conformance suite under Miri when I was worried if there was UB in my PR which introduced Source, and it took at least 4 hours (maybe much longer, I gave up and went to bed at that point).

Personally I do think the best tool for this particular job is the compiler. This is exactly what trait bounds are designed for.

[hyf0]

Not sure if this is an elephant in the room. How much cost for having Drop method on ast? Does this solve this leaking issue forever?

[overlookmotel]

Not sure if this is an elephant in the room. How much cost for having Drop method on ast?

I have not measured it, but I would imagine very significant. Lack of Drop is a major benefit of using an arena allocator. Boshen may be able to say more accurately.

Does this solve this leaking issue forever?

Yes it would. But an Arena trait, as outlined above, would also solve the problem, but with zero runtime cost - it uses the type system to make leaks impossible at compile time.