False C/C++(65) after rapid snippet replacement: identical source gets different diagnostics

Start with README.md, key-protocol-events.json, the full protocol trace, and the reconstructed t.cpp in the attached evidence ZIP. Reproduce the rapid snippet replacements and compare document versions 10 and 13 with their diagnostics; done means identifying a reproducible cause and preventing the false missing-semicolon diagnostic for the valid source.

Environment

• OS: Windows x64 (reported OS version: 10.0.26200.0)
• VS Code: 1.139.1 (from the captured initialize request)
• Microsoft C/C++ extension: 1.34.4, win32-x64
• Bundled native language service: 1.34.3.0
• Compiler: MSYS2 UCRT64 GCC 15.2.0, C:/msys64/ucrt64/bin/g++.exe
• C++ standard: gnu++17
• IntelliSense mode: windows-gcc-x64
• VS Code language: zh-cn
• File: t.cpp, UTF-8, CRLF, 189 bytes, no final newline
• Auto Save: afterDelay
• Workspace: local multi-root workspace with a C++ competitive-programming folder and a separate Python folder; the captured file is a standalone C++ source file.
• Remote / SSH / WSL / container: none

### Bug Summary and Steps to Reproduce

[cpptools-language-service-evidence.zip](https://github.com/user-attachments/files/32859601/cpptools-language-service-evidence.zip)

## Bug summary

After rapidly replacing a C++ file with a user snippet, IntelliSense intermittently reports C/C++(65), "expected a ';'" (Chinese UI: 应输入“;”), on the final closing brace of main(). The expanded source is valid and passes GCC syntax checking.

The attached protocol trace records two byte-identical source versions in the same session. Version 10 receives no diagnostics, while version 13 receives error 65. Both are complete passes with clearExistingDiagnostics=true. The failing result is for the current document version; this is not merely an old-version diagnostic remaining on screen.

## Steps to reproduce (intermittent)

1. Use the environment and configuration below. Auto Save is enabled.
2. Add the snippet from cpp-snippet.json in the attachment to the C++ user snippets. Its prefix is kj.
3. Create/open t.cpp, type kj and accept the snippet from the completion list. The default placeholder expands to 100005.
4. Select the entire document, type kj to replace the selected contents, then immediately accept the same snippet again. Repeat this rapid replacement a few times if necessary.
5. Sometimes the final closing brace at line 13 acquires C/C++(65), even though the complete snippet is present. Saving and waiting do not necessarily clear it; the captured error was repeated about 34 seconds later without another document edit.

The issue does not occur on every expansion. The protocol records the edits and snippet replacement, not the physical acceptance key.

## Expected behavior

The fully expanded valid source should have no missing-semicolon diagnostic, regardless of how quickly the same text was inserted.

## Captured evidence

| Time | Document version | Event / result |
|---|---:|---|
| 22:02:47 | 10 | kj is replaced by the entire valid 189-byte snippet |
| 22:02:48 | 10 | Complete pass, diagnostics=[], clearExistingDiagnostics=true |
| 22:02:49 | 11 / 12 | The entire document is replaced by k, then j is added |
| 22:02:49 | 13 | kj is replaced by exactly the same complete snippet |
| 22:02:50 | 13 | Complete pass, C/C++(65) at line 13, clearExistingDiagnostics=true |
| 22:02:50 | 13 | didSave occurs after the first failing result |
| 22:02:51 and 22:03:24 | 13 | The same diagnostic is returned again |

The source reconstructed from versions 10 and 13 is byte-identical. Each snippet expansion was sent as one complete replacement of kj; the trace does not show a partial snippet being sent. No C++ configuration update occurred between those two versions.

Compiler verification on the reconstructed failing source:

```text
C:/msys64/ucrt64/bin/g++.exe -std=gnu++17 -fsyntax-only t.cpp
Exit code: 0
```

Configuration and Logs

The attachment cpptools-language-service-evidence.zip contains:

- cpp-diagnostics-sanitized.txt: C/C++: Log Diagnostics output (21:45 capture).
- cpp-runtime-sanitized.txt: C/C++ Debug runtime output (a separate 21:53 capture).
- cpp-protocol-sanitized.txt: full cpptools client protocol trace from the decisive 22:02-22:03 reproduction.
- key-protocol-events.json: a smaller excerpt to help inspect document changes and diagnosis results.
- c_cpp_properties.json, cpp-snippet.json and the exact reconstructed t.cpp.
- README.md: evidence interpretation, source line references and redaction notes.

### c_cpp_properties.json


{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${default}"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "compilerPath": "C:/msys64/ucrt64/bin/g++.exe",
            "cStandard": "c17",
            "cppStandard": "gnu++17",
            "intelliSenseMode": "windows-gcc-x64"
        }
    ],
    "version": 4
}


### Relevant settings recorded during diagnosis


{
    "C_Cpp.default.compilerPath": "C:/msys64/ucrt64/bin/g++.exe",
    "C_Cpp.default.includePath": [
        " C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/include",
        "C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../include",
        "C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/include-fixed"
    ],
    "C_Cpp.errorSquiggles": "enabled",
    "C_Cpp.loggingLevel": "Debug"
}


For the decisive client trace, cpptools.trace.server was set to verbose.

**Known configuration caveat:** The first manually supplied includePath has a leading space. This was present during capture, and the logs preserve it. The correct same directory also appears in compiler-discovered system include paths. This configuration did not change between the passing and failing versions. A controlled retest after fixing that space has not been captured, so its possible contribution is not ruled out.

Personal home/project paths and one workspace-storage identifier were replaced consistently in the attached logs. Compiler paths, source text, timestamps, document versions, diagnostic fields and log line ordering were preserved. The diagnostics/runtime files are earlier captures and should not be treated as synchronized with the protocol trace.

Please see the ZIP attachment uploaded with this report.

Other Extensions

Other installed extensions:

• formulahendry.code-runner 0.12.2
• MS-CEINTL.vscode-language-pack-zh-hans 1.131.2026090407
• ms-python.debugpy 2026.6.0
• ms-python.python 2026.4.0
• ms-python.vscode-pylance 2026.4.1
• ms-python.vscode-python-envs 1.38.0

This list identifies installed extensions, not proof that each was active during reproduction. A successful clean-profile reproduction with all other extensions disabled has not yet been obtained; extension interaction has not been fully ruled out.

### Additional context

The same symptom was also observed with C/C++ 1.35.2 pre-release before switching to 1.34.4. The attached decisive trace is from 1.34.4.

Increasing C_Cpp.intelliSenseUpdateDelay to 3000 ms did not resolve the intermittent symptom in earlier attempts. Reloading the window or resetting IntelliSense was observed to clear it temporarily.

The evidence establishes a current-version false diagnostic from the language service. An incremental document/analysis state problem is a hypothesis, not a confirmed internal root cause. The trace alone cannot distinguish an internal document-buffer problem from parser/cache state or identify a particular race. The first failing result precedes the subsequent didSave notification, so Auto Save is not established as the direct trigger.

I can provide further targeted diagnostics if needed.