refactor(oxlint/lsp): IsolatedLintHandlerFileSystem is now a FxHashMap

[Sysix]

The language server wants to lint in the future multiple files at the same time.
These files could still be in memory, so extend IsolatedLintHandlerFileSystem to be a FxHashMap

[Sysix]

• fix(oxlint/lsp): report diagnostics referencing another file #16715
• refactor(oxlint/lsp): accept multiple files inside LintRunner #16668
• refactor(oxlint/lsp): use fs as param in TsGoLintState, instead of source text #16667
• refactor(oxlint/lsp): IsolatedLintHandlerFileSystem is now a FxHashMap #16666 👈 (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.

[Copilot]

Pull request overview

This PR refactors the IsolatedLintHandlerFileSystem struct in the language server's linter module to support multiple files. Previously, the struct held a single file path and its source text. Now it uses a FxHashMap<PathBuf, Arc<str>> to store multiple files, enabling better support for cross-file linting scenarios.

Key Changes:

• Replaced single-file storage (path_to_lint, source_text) with a FxHashMap for multiple files
• Changed from a new() constructor to an add_file() method with Default derive for incremental file addition
• Updated read_to_arena_str implementation to check the map before falling back to disk reads

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[charliecreates]

The change to a FxHashMap<PathBuf, Arc<str>> enables multi-file in-memory linting, but the current lookup depends on exact Path equality, which is fragile in an LSP/workspace environment and can cause unexpected disk fallbacks. Also, add_file silently overwrites existing entries, which may hide bugs once multiple files/snapshots are inserted. Addressing path normalization and clarifying overwrite semantics would make the new design more robust.

Additional notes (3)

• Compatibility | crates/oxc_language_server/src/linter/isolated_lint_handler.rs:42-42
  Using PathBuf as the key means lookups only hit for exact paths. In an LSP setting, the same file may be referenced via different but equivalent representations (relative vs absolute, different casing on case-insensitive filesystems, symlinks, etc.). If the linter resolves/normalizes paths internally (or if callers provide different forms across calls), you’ll silently miss the in-memory content and fall back to disk—exactly the scenario this refactor is trying to avoid.

At minimum, consider normalizing keys at insertion and lookup (e.g., canonicalize relative-to-root, or consistently use an absolute path derived from the workspace root). If canonicalization is too expensive or can fail for in-memory-only paths, a best-effort normalization (e.g., root_path.join(path) / dunce::simplified) would still reduce misses.

• Maintainability | crates/oxc_language_server/src/linter/isolated_lint_handler.rs:42-46
add_file currently overwrites any existing entry for the same path without making that explicit. If multiple in-memory snapshots are added (which is likely once you lint multiple files concurrently), accidentally inserting the same path twice could hide a bug and make the chosen snapshot depend on insertion order.

If overwriting is intended, it’s worth documenting; otherwise consider guarding against duplicates (or exposing a replace_file vs add_file distinction).

• Maintainability | crates/oxc_language_server/src/linter/isolated_lint_handler.rs:120-127
IsolatedLintHandlerFileSystem now keeps a FxHashMap<PathBuf, Arc<str>>, but lint_path still constructs a fresh filesystem per lint invocation and only inserts the currently-linted file. That means the refactor doesn’t actually enable “lint multiple files at the same time / still in memory” yet—there’s no way to populate additional in-memory dependencies (e.g., imported modules) for the same run, and no way to share the same FS across concurrent runs.

If the intent is to support future cross-file linting, consider threading an IsolatedLintHandlerFileSystem (or some “overlay” FS) from the LSP layer into lint_path, so it can include all open buffers for a workspace snapshot. Otherwise this change mainly alters internal representation without exposing the capability the PR description suggests.

Summary of changes

What changed

• Refactored IsolatedLintHandlerFileSystem from holding a single (path, source) pair to a multi-file in-memory store backed by rustc_hash::FxHashMap<PathBuf, Arc<str>>.
• Replaced the constructor new(path_to_lint, source_text) with #[derive(Default)] plus an incremental add_file(path, content) API.
• Updated RuntimeFileSystem::read_to_arena_str to first check the in-memory map and fall back to read_to_arena_str(path, allocator) for disk reads.
• Updated the lint flow to build the FS via default() then add_file(...) before calling runner.run_source(..., &fs).

[camc314]

Merge activity

• Dec 13, 12:33 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Dec 13, 12:33 PM UTC: camc314 added this pull request to the Graphite merge queue.
• Dec 13, 12:38 PM UTC: Merged by the Graphite merge queue.