Repository navigation
Tags: mcpp-community/mcpp-plugins
Tags
0.19.1: json::value compiles under clang with libstdc++, and CI reads… … every build program as an editor does (#47) `mcpp::plugins::json::value` held `std::vector<std::pair<std::string, value>>`. Under clang with libstdc++'s `std` module the pair is instantiated while `value` is incomplete, so `mcpp.plugins` failed to compile and an editor's clangd -- which reads a GCC project with exactly that combination -- showed every `import mcpp.…;` of a build program as a missing module. GCC and clang with libc++ accept the code, so no build ever failed. A member is now a plain struct `member { first; second; }` and `get()` is defined once both types are complete. `members` is used only inside the lib root and the fields keep their names, so the change is source-compatible. CI gains the two combinations it did not compile: `toolchain-llvm` builds and runs the toolchain-neutral fixtures under llvm@22.1.8 with libc++ (the Qt fixtures configure only, since Qt's Linux binaries are built against libstdc++), and `toolchain-editor` reads every fixture's `build.mcpp` with mcppls 0.0.15 over the GCC toolchain and fails on any error or on a file it did not read. On the previous code 34 of 37 fixtures fail there. docs/plugin-development.md §4 states the rule: a plugin is the C++23 that all three accept, with the differences met so far. The editor lane configures each fixture before reading it, as a project is configured before it is opened: on a fresh runner the build database otherwise describes no build program for a fixture whose toolchain or SDK is not yet provisioned. Closes #46
0.19.0: one resolver for a member's tool, payloads installed on reque… …st, and a toolchain a build program states Every member answers where the tool it runs comes from in one order, and a choice made in a build program never asks for the payload. Engine floor: mcpp 2026.10.1.3.
PreviousNext