Holding note, because you are owed one before any review verdict.

On #1989 you asked two direct questions:

Is the ^[A-Z0-9_]*_(API|EXPORT|IMPORT|DLLEXPORT|DEPRECATED)$ shape acceptable as the candidate-macro filter, or would you prefer an explicit config-driven list only (option 2)?

Since this changes what gets extracted (per CONTRIBUTING), may I open a focused PR for (1)+(2)?

Nobody answered. You did the right thing by asking, waited, and then built it anyway rather than letting the report rot — but this PR's description calls it "the agreed option 1", and I want to be straight with you: it was never agreed, because we never replied. That is our failure, not a liberty you took.

I have put the direction question — heuristic shape versus config-driven defines versus both — in front of the maintainer now, and I will bring you a real answer rather than letting it sit again.

Two things I can say already, having read the diff rather than the summary:

The report is exemplary. Naming UBT's /D "MODULE_API=" and CMake's generate_export_header() as the mechanism, then pinning it to three public headers — spdlog logger.h:50, fmt os.h:222, protobuf descriptor.h — turns "my code doesn't index" into a defect anyone can reproduce in a minute. Enumerating three fixes with costs, and asking which we wanted, is more than most maintainers get.

And the implementation is careful in the places that are easy to get wrong. skip_raw_string handles the fact that " is a legal d-char, so R"""(...)""" does not derail the scan; skip_non_code handles line-spliced // comments, where a backslash before the newline continues the comment; the >= slen + 2 prefix rule keeps a single-letter X_API out; and the uncertain paths return -1 and stop collecting rather than guessing. Failing toward not injecting a define is the right direction for a heuristic that changes what gets extracted.

None of that decides the direction question, which is genuinely the maintainer's. But it does mean that if the answer is yes, this is in good shape.

Thank you for the patience, and sorry it took a PR to get a reply.

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

Thanks for the clarification. I may be interpreting the timeline differently, so I checked the issue history.

Before opening this PR, I asked whether to pursue the heuristic option 1 or the config-driven option 2, and whether to combine them. The reply on #1989 explicitly asked me to "open a focused PR for option 1 only" and specified the candidate cap, negative controls, no user-configured define plumbing, and the class/struct/enum/free-function test boundary: #1989 (comment)

I used that as the scope for this PR. I agree that the exact regex was not approved character-for-character; the implementation made the candidate filter deliberately conservative and bounded. If the exact filter or any other part of the scope should change, I am happy to adjust it.

I just wanted to clarify that the option-1 direction and scope were discussed in the issue before implementation.

You are right, and thank you for correcting the record.

The maintainer reply on #1989 did explicitly ask for a focused PR implementing option 1 with the bounded candidate scan and the stated negative controls. Our earlier comment here saying that the direction had never been agreed was wrong. I am sorry: you followed the scope we gave you.

The option-1 direction therefore remains the approved scope. The exact candidate filter and implementation still receive normal review on their merits, but you do not need to re-litigate why this PR exists. Thank you for responding with the thread reference and keeping the correction factual.

Rebased onto the latest main (2f9828d) and resolved the conflict in tests/test_extraction.c by preserving both the upstream extraction tests and the #1989 regression coverage. The PR remains a single commit and still changes only the four intended files.

The rebased files pass single-file compilation and clang-format checks locally. The full sanitizer test runner cannot be linked in the local MinGW environment because its sanitizer runtime/spec file is unavailable; the refreshed CI matrix is running now.

Direction settled — thank you for building this, and apologies that the two questions on #1989 went unanswered before you did. That was on us, and the answer was yes.

The zero-config shape rule (option 1) is accepted as the default: the candidate collection is bounded and lexically careful, the recovered definitions go through the line-mapping / visibility / qualified-name gates before they replace anything, and explicitly configured defines keep priority. That is the right layer and the right amount of caution.

Two things so you know what happens next:

1. Merge sequencing. Your branch is green and cleared. Three other PRs that also append to tests/test_extraction.c (fix(extraction): reach a Swift URL built by a constructor #1976, fix(elixir): populate first_string_arg for Elixir calls #1721, fix(elixir): Phoenix channel extraction is unreachable in both branches #1730) are mid-way through their CI right now; landing yours first would void all three matrices in a very loaded queue, so I will let them land and then bring this branch up to date once and merge on green. Nothing needed from you — if the branch update needs a hand I will say so here.

2. Follow-up, not a blocker: an explicit override for the rule (extend the candidate set for macros the shape rule cannot see, exclude a name that is a genuine symbol) — the reporter's option 2 layered on top of yours. Filed as Export-macro recovery: project-level override for the candidate rule (follow-up to #2005) #2049; you are the natural person to take it if you want to, no timing pressure.