perf(linter/jsdoc/require-param): compile checkTypesPattern regex once

[connorshea]

AI Disclosure: Generated with Claude Code, reviewed and tested by me. I don't think there's a particularly good reason to use a RwLock like this?

This can be split into separate PRs if preferred, as it also adds the type for this rule to the generated definitions and JSON Schema.

The rule kept compiled checkTypesPattern regexes in a global OnceLock<RwLock<FxHashMap<String, Regex>>>. Every run() on a JSDoc-documented function:

• cloned the pattern String to use as the map key,
• took the RwLock write lock even on cache hits, serializing all linter threads through a single lock, and
• held the guard across the entire parameter check.

The pattern is fixed at configuration time, so the cache is unnecessary: this PR deserializes the option directly into a Regex field on the config (same approach as #24412 / #24417) and deletes the cache entirely.

Benchmark

Paired interleaved samples (N=40), release builds, fixture of 64 files × 400 fully-documented JSDoc functions (25,600 run() calls, all hitting the regex path, zero violations) with only jsdoc/require-param enabled:

Run	Baseline (8de6fca)	This PR	Result
Rule enabled	56.95 ms	18.25 ms	3.12×, t=132.8, 40/0 wins
Parse-only null control (same fixture)	11.05 ms	10.75 ms	1.03×, t=1.5 — noise

Subtracting the ~11 ms parse floor, rule execution drops from ~46 ms to ~7 ms (~6.4×). The win is mostly the removed cross-thread lock contention, so it scales with file count on multi-core machines.

Correctness

• Diagnostics are byte-identical between baseline and this PR on a mixed pass/fail canary, under both the default config and a custom checkTypesPattern config (which changes reporting, confirming the option deserializes and takes effect).
• oxc_linter lib tests (1,169), oxlint tests (396), and clippy pass; the generated website rule-doc page is byte-identical (schemars(with = "String", default) preserves the documented default).

Invalid patterns are now a config error, not a panic

An invalid checkTypesPattern previously panicked lazily, on the first checked function. It now fails config loading with a proper diagnostic:

Failed to parse oxlint configuration file.

  x Invalid configuration for rule `jsdoc/require-param`:
  |   regex parse error:
  |     ^(unclosed
  |      ^
  | error: unclosed group

To get there, two things changed:

• The regex deserializer lives in utils/config.rs alongside the existing deserialize_regex_option / deserialize_regex_vec / deserialize_required_regex_option family, and builds via RegexBuilder with D::Error::custom like they all do.
• from_configuration propagates the serde error instead of dropping it with .ok(). The linter already has the plumbing for this — config/rules.rs turns an Err into OverrideRulesError::RuleConfiguration — the .ok() was just discarding it.

Behavior change worth flagging

Now that from_configuration no longer swallows errors, this config's deny_unknown_fields is load-bearing for the first time. A config carrying an eslint-plugin-jsdoc option that oxc doesn't implement (e.g. unnamedRootBase) previously fell back to defaults silently; it now fails to load with an "unknown field" error. No lint results change, but a user porting an eslint-plugin-jsdoc config that oxc previously tolerated will now see a config error.

That surfaced in the ported test suite: eight cases configure unnamedRootBase (×5), enableFixer (×2), enableRootFixer, and autoIncrementBase, none of which this rule implements. They're commented out, and the snapshot is regenerated accordingly.

If maintainers would rather keep the lenient behavior, the alternative is to validate checkTypesPattern up front and keep the .ok() fallback for everything else — that removes the panic without touching any test or changing config tolerance. Happy to switch.

🤖 Generated with Claude Code

[codspeed-hq]

Merging this PR will not alter performance

✅ 5 untouched benchmarks
⏩ 66 skipped benchmarks¹

---

_{Comparing perf/linter-require-param-regex (423424c) with main (8de6fca)}

Footnotes

1. 66 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[camc314]

thanks!

[camc314]

Merge activity

• Jul 13, 9:26 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jul 13, 9:26 AM UTC: camc314 added this pull request to the Graphite merge queue.
• Jul 13, 9:32 AM UTC: Merged by the Graphite merge queue.