fix(linter): prevent unsound use of Allocator across threads

[overlookmotel]

Allocator is currently Sync, but it shouldn't be - Allocator is not thread-safe and allocating into it in multiple threads can cause data corruption or, in worst case, writing out of bounds. I intend to remove the impl Sync for Allocator in a PR to follow.

The code altered in this PR was relying on Allocator being Sync. It was not actually dangerous as it stood, because access to the Allocator was synchronized by always holding a lock on the messages Mutex while using it. However, I suspect this was more by accident by design, and it was rather fragile.

This PR introduces a MessageCloner struct which provides a safe API which ensures access to the Allocator is correctly synchronized.

It's unfortunate to introduce a 2nd Mutex, and the Mutex inside MessageCloner is accessed more than necessary - on each turn of the loop in the map loops, instead of just once at the top of the loop. However, I couldn't find a way to achieve that without resorting to fragile unsafe code.

In any case, from what I can understand, the ultimate callers of both run_source and run_test_source convert the cloned Messages into other owning types (DiagnosticReport or Report) anyway. Therefore the double-conversion may be wasteful anyway, and we might be better off trying to convert to these owned types earlier, and avoid using an Allocator at all in these methods.

I also am wondering in what circumstances error messages would contain arena-allocated strings, and whether Message could instead contain Cow<'static, str>s, in which case the Allocator becomes unnecessary, and cloning would be cheaper.

Delving into the depths of the linter to understand all this is a bit beyond me, so I hope we can accept this imperfect solution for now, and refactor to remove/optimize it later on.

[overlookmotel]

• refactor(allocator): replace AtomicUsize with Cell<usize> in AllocationStats #13043
• refactor(semantic): implement Send and Sync for ScopingCell #13042
• fix(allocator): remove unsound Send impl and tighten Sync requirement for HashMap #13203
• fix(allocator): remove unsound Send impl and tighten Sync requirements for Vec #13041
• fix(allocator): remove Vec::bump method #13039
• fix(allocator): remove Clone impl from Vec #13040
• fix(allocator): remove unsound impl Sync for Allocator #13033
• fix(linter): prevent unsound use of Allocator across threads #13032 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #13032 will not alter performance

_{Comparing 08-12-fix_linter_prevent_unsound_use_of_allocator_across_threads (b0558a4) with main (ab685bd)¹}

Summary

✅ 34 untouched benchmarks

Footnotes

1. No successful run was found on main (b0558a4) during the generation of this report, so ab685bd was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Copilot]

Pull Request Overview

This PR addresses a thread-safety issue with the Allocator type by preventing unsound use across multiple threads. The main change introduces a MessageCloner struct that provides synchronized access to an Allocator for cloning Message objects safely in multi-threaded contexts.

• Introduces MessageCloner wrapper with mutex-based synchronization for thread-safe Allocator access
• Updates function signatures to take &mut Allocator instead of &Allocator to enforce exclusive ownership
• Replaces direct clone_in calls with MessageCloner::clone_message method calls

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
crates/oxc_linter/src/tester.rs	Updates allocator to mutable reference and passes it to run_test_source
crates/oxc_linter/src/service/runtime.rs	Implements MessageCloner struct and updates methods to use synchronized message cloning
crates/oxc_linter/src/service/mod.rs	Updates method signatures to accept mutable allocator references
crates/oxc_language_server/src/linter/isolated_lint_handler.rs	Updates allocator usage to mutable references throughout the handler

[Sysix]

Removed myself as a reviewer because alllocation and async is not my strength.
But maybe this info could still help you:
MessageWithPosition is a language server struct. I implemented the lifetime only because it reflects the Message struct.
Because of that, I needed the Allocator in the run_source for the lifetime.
Just wanted to drop this info, so you understand why this was implemented the way it was.

[overlookmotel]

@Sysix Thanks for the context. The linter is all new to me, so I can't say I understand any of this! It looks to me like the root cause might be that Message doesn't need a lifetime, but I don't know enough to evaluate if that's correct or not.

I've written up observations in #14563 so we can investigate further later on when we have time.

For now, going to merge this.

[overlookmotel]

Merge activity

• Aug 13, 11:47 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Aug 13, 11:47 AM UTC: overlookmotel added this pull request to the Graphite merge queue.
• Aug 13, 11:51 AM UTC: Merged by the Graphite merge queue.