C parser still indexes call sites as functions and misses nginx-style definitions

[justrach]

Problem

After deploying codedb release/0.2.579 to api.wiki.codes and reindexing a C validation set, C symbol coverage is no longer zero, but parser precision/recall still needs work.

Prod evidence

Validation reindex on 2026-04-26:

curl-curl        files=4279 symbols=14949
nginx-nginx       files=526  symbols=4583
openssl-openssl  files=3997 symbols=61892
sqlite-sqlite    files=2178 symbols=18339

Good hits:

/api/curl-curl/symbol?name=Curl_close
  -> lib/url.c, kind=function, detail="CURLcode Curl_close(struct Curl_easy **datap)"

/api/curl-curl/symbol?name=curl_easy_init
  -> lib/easy.c, kind=function, detail="CURL *curl_easy_init(void)"

/api/openssl-openssl/symbol?name=SSL_new
  -> ssl/ssl_lib.c, kind=function, detail="SSL *SSL_new(SSL_CTX *ctx)"

Bad false positives:

/api/curl-curl/symbol?name=curl_easy_perform
  -> 89 results, mostly docs/examples call sites and strings such as:
     fprintf(stderr, "curl_easy_perform() failed: %s\\n",

Nginx recall gap:

/api/nginx-nginx/symbol?name=ngx_http_init_connection      -> 0
/api/nginx-nginx/symbol?name=ngx_http_create_request       -> 0
/api/nginx-nginx/symbol?name=ngx_http_process_request      -> 0
/api/nginx-nginx/symbol?name=ngx_http_finalize_request     -> 0
/api/nginx-nginx/outline?path=src/http/ngx_http_request.c  -> 12 symbols, mostly includes/calls, not the main function definitions

Example nginx false positives from outline:

SSL_CTX_get_verify_mode, kind=function, line 991
SSL_get_options, kind=function, line 998
ngx_strcasestrn, kind=function, line 1928

These are call expressions inside function bodies, not definitions.

Expected behavior

The C parser should index high-confidence declarations/definitions and skip call expressions inside bodies/strings/log messages.

For issue #319 follow-up, useful acceptance criteria would be:

• curl_easy_perform should either return its definition only, or no hit if the definition is macro/alias-backed and not confidently parsed.
• nginx request functions should be detected in src/http/ngx_http_request.c.
• function calls such as SSL_get_options(...) inside a statement should not become kind=function symbols.
• strings containing foo() should not become function symbols.

Cloud validation context

The cloud reindex itself worked; this is now parser quality, not deployment. api.wiki.codes has the validation data live for curl/nginx/openssl/sqlite.

[justrach]

Additional cloud validation on 2026-04-26

Reindexed five more C/C++-heavy repos on api.wiki.codes with the same 0.2.579 engine:

git-git              4533 files  42063 symbols  25336 C/C++ symbols
redis-redis          1739 files  21628 symbols  21047 C/C++ symbols
neovim-neovim        3728 files  22507 symbols  22027 C/C++ symbols
ggerganov-ggml       1129 files  14811 symbols  14504 C/C++ symbols
ggerganov-llama-cpp  2531 files  30975 symbols  21830 C/C++ symbols

What looks good:

redis-redis createClient       -> src/networking.c definition
redis-redis processCommand     -> src/server.c definition
redis-redis lookupKeyRead      -> src/db.c definition
redis-redis serverCron         -> src/server.c definition
neovim-neovim nvim_main/main   -> src/nvim/main.c definition
neovim-neovim nlua_init        -> src/nvim/lua/executor.c definition
neovim-neovim eval_init        -> src/nvim/eval.c definition

More parser issues found:

1. Multi-line C function signatures are missed.

git-git /api/git-git/symbol?name=cmd_status -> 0
content exists in builtin/commit.c:
  int cmd_status(int argc,

cmd_commit and cmd_status appear to be split across lines in builtin/commit.c, so they are not indexed even though the content is present.

2. Function calls and string literals are still indexed as functions.

Examples:

git-git builtin/commit.c outline has string-derived symbols: fixup, token
git-git parse_options returns strings/call sites from t/helper/test-parse-options.c
ggml src/ggml.c outline has defined(...) as kind=function from preprocessor conditionals

3. struct <type> * function(...) return types can be misclassified as struct definitions.

ggerganov-ggml /api/ggerganov-ggml/symbol?name=ggml_init -> 0
symbols.parquet has:
  name=ggml_context kind=struct_def detail="struct ggml_context * ggml_init(struct ggml_init_params params) {"

Expected symbol should be ggml_init with kind function.

4. C++ recall is still uneven.

ggerganov-llama-cpp llama_backend_init -> found in src/llama.cpp
ggerganov-llama-cpp llama_decode / llama_model_load_from_file / llama_init_from_model / llama_tokenize -> 0 symbol hits, content search mostly finds call sites first
src/llama-model.cpp outline -> 0 symbols

So the deployment confirms the parser has useful recall for ordinary C projects like Redis/Neovim, but the next fix should target multi-line signatures, function-call filtering, struct-pointer returns, and C++ method/function shapes.