Skip to content
| Marketplace
Sign in
Visual Studio Code>Other>clang func completionNew to Visual Studio Code? Get it now.
clang func completion

clang func completion

noname

|
2 installs
| (0) | Free
Completes the missing counterpart of a C function (declaration without definition, or definition without declaration)
Installation
Launch VS Code Quick Open (Ctrl+P), paste the following command, and press enter.
Copied to clipboard
More Info

clang function completion

A Visual Studio Code extension that suggests only the missing counterpart of a C function.

  • In a .c file, where a function body belongs, it offers functions that are declared but not defined, and inserts a body snippet with braces (the cursor lands inside them).
  • In a .h file, or in the prototype block at the top of a .c file, it offers functions that are defined but not declared, and inserts the signature followed by ;.

Functions that already have both sides are excluded from the suggestions. That narrowing is deliberate — it keeps the list from duplicating clangd's ordinary token-match completion, and it is the whole point of this extension. It answers the "I declared it, but nothing is suggested when I go to write the body" problem directly.

Since 1.1.0 there is a second, lower-priority tier for the opposite order of work: a function you called before writing it. If a name is called somewhere in the workspace but has no declaration and no definition anywhere, it is offered too — and picking it inserts the name alone, with no return type, no parameter list and no braces. A call site tells you the argument expressions, never their types, so any signature built from one would be guesswork, and a wrong signature costs more to correct than an absent suggestion. These candidates sort below the ones above and are labelled 呼び出しのみの関数(宣言・定義なし / 名前のみ挿入).

Usage

  1. Open a C project in VS Code.
  2. Start typing a function name where you would write the body in a .c file, or in a .h file / prototype block.
  3. Pick the function whose counterpart is missing from the suggestion list.

Typing the type tokens first, as in static void fun, also works. Text you have already typed is replaced rather than duplicated — typing as far as fun and then accepting inserts the complete static void fun(...).

When inserting a definition, extern is not carried over. It is a qualifier that only means something on a declaration, so it is stripped automatically.

How It Works

  • On activation, the extension scans the whole workspace and caches the list of function declarations and definitions.
  • Saving a target file (.c .C .cpp .h .hpp .hxx .cxx) refreshes the cache for that file only.
  • Deleting or renaming a file clears the cache, which is rebuilt on next access.

Requirements

  • Visual Studio Code version 1.104.0 or higher

Installation

This extension is not published on the Marketplace. Install it from a .vsix file.

  1. Open the Extensions view in VS Code.
  2. Choose Install from VSIX... from the ... menu at the top right.
  3. Select the distributed .vsix file.

Known Limitations

  • Source files are read as UTF-8. In a Shift-JIS file, a multibyte character whose trailing byte is 0x5C (the same byte value as a backslash) inside a string literal can make the comment/string masking logic mistake where that string ends. Identifiers such as function and type names are ASCII only, so extraction results stay correct even when this happens.
  • Function signatures are extracted with regular expressions, not a real C parser. Post-macro-expansion forms and complex declarations (a function returning a function pointer, for example) may not be recognized.
  • The workspace scan is bounded: at most 5000 files, 4MB per file, and 12 directory levels deep. When a limit is hit, or a file cannot be read, one warning is shown per scan — a definition in a file that was skipped would be read as "not defined", leading to an offer to insert a duplicate definition.

Input shapes that break brace counting (found by adversarial testing, 1.1.0)

The extension tracks how deep in braces each line sits, in order to tell a function body from file scope. Five input shapes desynchronize that count. Each one can make a declaration or a definition go unrecorded, which again leads to an offer to insert a duplicate definition — check the signature before accepting. None of them causes a wrong call-only suggestion: when a file's brace depth does not return to zero, that file contributes no call names at all.

  • #ifdef and #else branches that both open a brace. The extension does not evaluate macros, so both branches survive and the count gains one brace too many. Solving this correctly requires a preprocessor, which is out of scope for this extension.
  • A preprocessor line continued with a trailing backslash: the continued line is treated as ordinary code, so a brace on it is counted although C considers it part of the directive.
  • C++ raw string literals R"(...)" containing a quote, which end the masking early.
  • The C++14 digit separator, as in 1'000 — the apostrophe is read as the start of a character literal and blanks the rest of the line.
  • Compound initializers at file scope, { init_a(), init_b() }, which are counted as being inside a body.

Non-ASCII identifiers are a separate limitation: the adjacency check looks only at ASCII word characters, so a form like 変数foo() is not split correctly.

Known Issues (carried over from v1.0.0)

Fixed in 1.1.0: a function-like macro whose body opens a brace (#define TEST_CASE(name) void test_##name(void) {) used to drop every later definition from the cache. The remaining items below are unchanged.

All of these fail in the same direction: a definition exists but is not found, so the extension offers to insert a duplicate one. Check the signature before accepting an insertion.

  • A definition that attaches * to the function name, such as char *get_buf(void), is not recognized (char * get_buf(void), with a space, is). If the header uses a space and the .c file does not, a duplicate definition is offered.
  • Definitions with CC-RL's __far / __near / __callt, or GNU RL78's __attribute__((interrupt)), between the type and the function name are not recognized.
  • An #if 0 whose #endif has not been written yet makes everything below it count as inactive code, hiding the definition just above as well.
  • Saving a file before the startup workspace scan finishes may leave that save out of the cache. Reopening the window resolves it.
  • Files with an uppercase .H extension are neither scanned nor treated as headers (this can lead to offering a function body in older CS+ projects).
  • File changes made outside VS Code — git pull, CS+ code generation — do not refresh the cache. Reopen the window.

Supported Languages

c and cpp (.c .C .cpp .h .hpp .hxx .cxx).

Release Notes

1.1.0

  • New lower-priority tier: functions called in the workspace but never declared or defined, inserted as the name only
  • Function-like macros excluded from that tier; files whose brace depth does not balance contribute no call names
  • Fixed a 1.0.0 bug where a macro body opening a brace dropped later definitions from the cache
  • Call extraction made linear in input length (a 262 KB single token went from 58.8 s to 8 ms)

1.0.0

  • Initial release
  • Declaration ↔ definition mutual completion
  • Context-aware insert format (body snippet vs. ;-terminated signature)
  • Whole-workspace scan with incremental cache refresh on save
  • Contact us
  • Jobs
  • Privacy
  • Manage cookies
  • Terms of use
  • Trademarks
  • Your Privacy Choices
  • Consumer Health Privacy
© 2026 Microsoft