fix: stop doctest regex overrun in constructor-name example

[Planeshifter]

Failing run: https://github.com/stdlib-js/stdlib/actions/runs/25195861572 (issue #11867, 2026-05-01)

Symptom:

lib/node_modules/@stdlib/utils/constructor-name/examples/index.js
   39:1   error  Displayed return value is `'String'`, but expected `undefined` instead  stdlib/doctest
  151:57  error  Unused eslint-disable directive (no problems were reported from 'no-buffer-constructor')

Root cause:

Error 1 (stdlib/doctest): The rule's RE_ANNOTATION regex contains a greedy [^;]* segment that matches newlines. Before the fix, noop() had a comment-only body with no semicolons. The regex anchored at \nfunction noop() {, its [^;]*; segment spanned across the function body and the trailing blank line, terminating at the ; of console.log( constructorName( 'a' ) );. The subsequent \n// token then matched \n// => 'String', so the rule fed the combined span to its VM sandbox as a single expression. A function declaration evaluates to undefined, not 'String', producing the observed mismatch.

Error 2 (unused eslint-disable): no-buffer-constructor is absent from all project ESLint rule files (etc/eslint/rules/). The inline disable directive on the Buffer line was stale.

Fix:

Two minimal edits to lib/node_modules/@stdlib/utils/constructor-name/examples/index.js:

1. Add return void 0; inside noop(). This places a ; inside the function body. The greedy [^;]* now terminates at return void 0;; the following \n} does not match \n//, so the false-association attempt fails and the regex advances correctly to console.log( constructorName( 'a' ) );.

2. Remove // eslint-disable-line no-buffer-constructor from the new Buffer(...) line. The rule is inactive; the directive serves no purpose.

Neither change affects runtime behavior. noop is passed to constructorName(noop) only to demonstrate a 'Function' result; its return value is never used. The test suite defines its own independent noop and is unaffected.

Validation:

• Regex trace confirmed by Reviewer A: RE_ESLINT_INLINE strips the eslint-disable-line comment before RE_ANNOTATION runs, leaving return; → the ; survives and terminates the match inside the function body. (Note: cycle 1 proposed return; with a disable comment; cycle 2 revised to return void 0; — no-useless-return only flags bare return;, not return expr;, so no suppression directive is needed.)
• no-void is set to 'off' in etc/eslint/rules/best_practices.js (line 1418); void 0 is permitted.
• Confirmed no-buffer-constructor absent from all etc/eslint/rules/ files.
• Two review cycles. Cycle 1: Reviewer C (style) requested changes — commit message too long (83 chars) and return; + disable comment idiom objected to. Cycle 2: all three reviewers approved.

Reviewer notes:

• Reviewer C (cycle 2) noted that the most idiomatic stdlib approach for an example noop would be require('@stdlib/utils/noop') rather than a local declaration with return void 0;. This is non-blocking: the current fix is correct and minimal. A maintainer may choose to apply the idiomatic refactor separately.
• Several other // eslint-disable-line no-buffer-constructor directives exist elsewhere in the repo (e.g., buffer/from-buffer, buffer/from-array). Those are out of scope for this PR but may warrant a follow-up sweep.

Related: issue #11867 (cluster 1 of that issue — symbol/async-iterator — is addressed separately in draft PR #11905)

Contributing Guidelines

• Read, understood, and followed the contributing guidelines

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
utils/constructor-name	$\color{green}126/126$ $\color{green}+100.00%$	$\color{green}12/12$ $\color{green}+100.00%$	$\color{green}1/1$ $\color{green}+100.00%$	$\color{green}126/126$ $\color{green}+100.00%$

The above coverage report was generated for the changes in this PR.

[kgryte]

@Planeshifter Seems like we need to make a more general fix here and not paper over by updating the example.

[kgryte]

As the lint error was already addressed, I'll go ahead and close. We still need to create a more general solution.