Initial.

[anhed0nic]

C++20 language support (NeverC ABI v1, no streams)

Summary

This pull request brings ISO C++20 language support to NeverC (latest released C++ standard at the time of this work), excluding iostream / stream facilities by deliberate product policy. The implementation spans frontend (parse / Sema / AST), NeverC-only C++ ABI v1 codegen and layout, a bundled neverc_cxx_runtime, and a non-stream standard library surface. With the remaining ABI/protocol depth items in this branch completed, C++20-minus-streams is feature-complete for NeverC’s stated scope.

Verification (full tree build and conformance tests) is intended to follow merge readiness of this surface; the conformance matrix lives at docs/roadmap/cpp20-conformance-matrix.md.

---

On NeverC

NeverC has been an unusually good fit for the kind of work many of us already do in security research and systems tooling. The project’s design choices are coherent: C23 as a clear default, an integrated linker, cross-compilation that does not require a scavenger hunt for SDKs, DynCode as a first-class pipeline, and built-in facilities (string, mimalloc, xorstr, strhash) that show up in real workflows rather than only in marketing bullets. The plugin API and phase model make the compiler feel extensible without demanding that every experiment become a fork of LLVM.

We have been using NeverC as a day-to-day compiler for research prototypes, freestanding and hosted targets, and dyncode-oriented builds. The experience is practical: one toolchain, predictable C semantics when you want them, and enough infrastructure that “compile this for the other OS” is not a separate project. Adding C++20 on that base is not a repudiation of NeverC’s C-first identity. It is an acknowledgment that the same people who benefit from NeverC’s C and DynCode story often also need to speak C++ fluently in small, deliberate programs—especially when the artifact under study was written in C++.

This PR is written in that spirit: extend NeverC where the research workflow demands it, keep the ABI and library policy under NeverC’s control, and refuse to drag in the parts of the C++ ecosystem that fight the project’s goals.

---

Motivation: C++ features for reverse engineering and proof-of-concept work

Heavy C++ applications dominate large parts of the software we reverse: game clients and anti-cheat stacks, browsers and renderers, industrial control and CAD, finance and trading systems, endpoint agents, and a long tail of proprietary services. The binaries are not “C with a class keyword.” They are shaped by constructors and destructors, virtual dispatch, template-generated specializations, RTTI-assisted paths, exception edges, lambdas and std::function-like erasure, coroutines in newer codebases, and module or unity-build packaging. Understanding those mechanisms in IDA, Binary Ninja, Ghidra, or a custom lifter is necessary but not sufficient. At some point the reverse engineer needs to re-express behavior—to build a POC, a harness, a shim, a fuzzer stub, or a minimal reimplementation of a protocol object graph.

That is where a C-only toolchain becomes a tax.

Matching the mental model of the target

When a target type is a polymorphic hierarchy with a non-trivial constructor order, a POC written as raw vtable pointers and manual this adjustment is possible, but it is fragile and hard to review. The same POC written with classes, bases, virtual methods, and ctor-initializer lists is closer to how the original authors (and the decompiler’s better days) think about the object. The point is not aesthetic preference. The point is reducing translation error between “what the binary does” and “what the harness does.” Every manual lowering of a C++ feature into C is a chance to get layout, lifetime, or dispatch wrong under time pressure.

Layout, ABI, and “close enough to call”

Research POCs often need to:

• Allocate and destroy objects the way the target expects (or close enough to exercise a path).
• Call virtual methods through a reconstructed or partially reconstructed vtable.
• Survive RTTI checks, dynamic_cast gates, or type-info comparisons.
• Link against or mimic runtime helpers (operator new, exception personality stubs, guard variables).

A compiler that can emit a documented NeverC C++ ABI v1—vtable layout, RTTI symbols, mangling, delete/dtor pairing—gives POCs a stable substrate. Full system-libstdc++ / libc++ / MSVC ABI compatibility is intentionally out of scope here; for many RE workflows that is acceptable or even preferable. What matters is repeatable object and call semantics under one toolchain, not dropping a research binary into a distro’s C++ runtime lottery.

Templates, concepts, and the code you wish you could type

Target code is full of templates. POCs do not need every specialization the vendor shipped, but they do need generic glue: thin wrappers, type traits, optional-shaped holders, span-like views, and constrained helpers so that harness code stays short. C++20 concepts and requires-clauses, even at research depth, make it easier to write POCs that fail early when a reconstructed type does not satisfy an assumed interface. That is debugging time saved when the alternative is a wrong overload silently selected in a sea of void*.

Lambdas, range-for, and the speed of writing a harness

Proof-of-concept quality is often limited by how fast a correct experiment can be written. Lambdas with captures, range-based for, auto, and constexpr evaluation are not about “writing applications.” They are about keeping the harness smaller than the insight. When the interesting part is a packet parser or a state machine recovered from a binary, the compiler should not force the harness into pre-C++11 shape. NeverC already optimizes for LLM- and human-friendly C; C++20 support extends that ergonomics to the subset of problems where C++ is the native language of the target.

Exceptions, noexcept, and real control flow

Many C++ codebases use exceptions at API boundaries even when the hot path is noexcept-ish. A POC that must trigger or survive catch blocks needs try/catch, throw, and a personality story. Conversely, a POC that must match a noexcept interface needs the declaration surface. Leaving exceptions entirely unimplemented forces reverse engineers back into ad hoc longjmp simulations that do not match the binary’s landing pads. Supporting the language feature set makes experimental code honest about control flow.

Coroutines and modern targets

Newer targets use C++20 coroutines for async I/O, job systems, and RPC. A research compiler that can parse and lower co_await / co_return / co_yield with a small runtime (__neverc_coro_*) lets POCs explore those control-flow graphs without first rewriting them as explicit state machines—useful when the goal is to validate understanding of the original, not to produce a shipping async stack.

Modules and BMI as a research boundary

Modules are part of C++20 whether or not every build system has caught up. A NeverC BMI scaffold (export blob, import read path) keeps the door open for isolated interface units in larger research codebases without requiring the full PCMity of Clang’s ecosystem. For RE-oriented monorepos of harnesses and reconstructed headers, that is a structural feature, not a checkbox.

Why this belongs in NeverC specifically

Putting C++20 into NeverC—rather than telling researchers to keep a second full Clang/MSVC install solely for POCs—preserves the project’s advantages: one driver, one linker story, one cross-compile path, DynCode adjacency, and plugin hooks. The C++ support is NeverC-shaped: own ABI, own runtime, own policy on the standard library. That is the correct trade for security research. We are not trying to replace a platform compiler for shipping applications. We are trying to make NeverC the place where C23, dyncode, and C++ POCs can live in one mental and physical toolchain.

---

What this PR delivers

Language and frontend

• C++20 language mode (-std=c++20 / gnu++20 / related aliases) as the target edition; C++23 is out of scope.
• Core C++ declaration and expression surface: classes, access control, nested-name-specifiers, references, this, constructors / destructors / methods, operator function-ids, inheritance (including virtual bases at layout level).
• Ctor-initializer lists: parse, Sema (CXXCtorInitializer, member/base builders), and ctor prologue emission for member initialization after vptr setup.
• Overload resolution with unresolved lookup, implicit conversion sequences, and user-defined conversion hooks.
• Templates: substitution for types/expressions/statements, function and class template instantiation paths, partial ordering scaffolds, NTTP type mapping from declarator pieces.
• Concepts / requires: requires-clause checking, requires-expressions, constraint composition (&& / || / !), concept-id soft satisfaction paths.
• Lambdas: closure types, call operator, typed parameter lists, capture-default and capture-ids, capture field typing and emission.
• Range-for: array and class ranges; member and free begin/end with call initializers; ADL-lite associated-namespace lookup.
• Exceptions and noexcept: try/catch AST and EH catch scopes, throw/rethrow runtime hooks, multi-level exception specifications.
• new/delete, named casts, typeid / RTTI hooks, constexpr/consteval evaluation depth.
• Coroutines: co_await / co_yield / co_return (CoreturnExpr) with runtime resume helpers.
• Modules: module name handling, BMI v0 writer/reader, export list scaffold, import injection of export names.

ABI, codegen, and runtime

• NeverC ABI v1 (Itanium-inspired, not interchangeable with system C++ ABIs by claim):
  • Vtables: [offset-to-top, RTTI, vfunc…], mangled _ZTV + length + name.
  • Virtual call through vptr slots.
  • VTT emission (_ZTT) for classes with virtual bases.
  • Primary-base-style vptr sharing in record layout; unique virtual base subobjects.
  • RTTI descriptors and dynamic_cast runtime entry points.
• Construct emission with constructor calls; delete paths invoking destructors; array-delete hooks.
• Driver linkage to neverc_cxx_runtime (runtime/cxx): new/delete, cxa_*, RTTI, guards, coroutine helpers, pure virtual, etc.

Library policy

• Broad non-stream standard library header scaffolds (type_traits, concepts, span, ranges, optional, memory, containers, concurrency headers, C library bridges, and related surface).
• Hard exclusion of iostream / stream facilities via NoStreams (see below).

Documentation

• Conformance matrix and ABI notes updated under docs/roadmap/cpp20-conformance-matrix.md.

---

Explicit non-goals

• iostream and stream-dependent library surface
• Binary compatibility with system libstdc++ / libc++ / MSVC STL
• C++23 language features
• Replacing NeverC’s C23-first defaults for users who do not opt into C++

---

Why streams are out (and should stay out)

This section is longer than a typical “won’t fix” note because the exclusion is easy to misread as incomplete work. It is not incomplete work. Leaving streams out is a feature of this design.

Streams are a different product

C++ iostreams are not “printf with <<.” They are a parallel I/O architecture: locales, facets, tied streams, formatting state machine, virtual streambuf overflow/underflow, synchronization with C stdio, and a header dependency graph that pulls an enormous amount of machinery into any translation unit that touches them. A research compiler that aims to stay understandable, embeddable, and cross-compilation-friendly should not accidentally become “also maintain a locale and iostreams stack.” That is a multi-year product line of its own. NeverC already has a clear I/O story for C and for its own builtins. Duplicating iostreams would not make RE POCs better; it would make the toolchain heavier and the failure modes stranger.

ABI and shared library gravity

In real toolchains, iostreams are where C++ runtime linkage becomes painful. libstdc++ / libc++ version skew, dual-ABI footnotes, iostreams tied to exception and RTTI configuration, and “it linked but crashed in std::ios_base::Init” are familiar failure modes. NeverC’s C++ support is explicitly NeverC ABI v1 with a bundled runtime. The moment we promise iostreams, we invite pressure to match platform library behavior, to ship locale data, and to debug initialization order across hosts. That pressure is hostile to a security-research compiler whose value is control and predictability, not drop-in replacement for a distro toolchain.

Hidden global state is the opposite of harness clarity

Stream objects carry formatting flags, width, precision, fill, exception masks, locale, and ties to other streams. std::cout and friends are global, constructible in surprising orders, and interactive with static initialization. Proof-of-concept code wants explicit buffers, explicit lengths, and explicit sinks—socket send, file write, hex dump, fuzzer callback. Iostreams encourage a style where “print the object” becomes a tangle of operator<< overloads and stateful manipulators. That style is fine in some application codebases. It is a poor default for reverse-engineering harnesses, where the reader should see bytes move without consulting the nightstand edition of the locale chapter.

Templates, concepts, and compile-time cost without research benefit

Iostream-related headers are among the most expensive includes in C++. They amplify compile times, instantiate large template piles, and create underspecified overload sets around operator<<. For LLM-assisted and human-authored research code alike, NeverC has emphasized small grammar and deterministic semantics on the C side. Pulling iostreams into the default C++ story would undermine that ethos precisely where feedback loops should be tight. A POC that needs text formatting can use C stdio, NeverC string, or a tiny purpose-built formatter. It does not need std::stringstream to justify C++20 classes and vtables.

Security and complexity surface

Stream implementations historically interact with locale, encoding, padding, and user-defined num_put / num_get facets. That is a wide surface for complexity and for bugs. Research toolchains should minimize mandatory surface area. Every additional global formatter is another thing to audit, stub, or misconfigure under freestanding and cross targets. DynCode and constrained environments make the problem sharper: you often do not want locale machinery in the image at all.

Pedagogical and cultural capture

Iostreams taught a generation that “C++ I/O” means << and >>. That pedagogy is sticky. If NeverC ships streams “because C++ has them,” every tutorial and every generated snippet will drag them in, and the project will spend its life explaining performance, binary size, and linkage. By hard-erroring stream headers under NoStreams, we make the policy visible and machine-checked. The compiler is allowed to say: this is C++ for types, objects, generics, and control flow—not a second standard I/O stack.

What we expect people to use instead

• C stdio and POSIX/Win32 I/O where platform APIs are the point
• NeverC string and existing builtins for text and memory discipline
• Explicit span/buffer APIs from the non-stream library surface
• Purpose-built dump/hex/log helpers in the harness

That combination is enough for serious POC work. It keeps dependencies readable. It keeps freestanding and cross builds sane.

A meandering but sincere conclusion on streams

It is tempting to treat iostreams as mandatory for “real C++.” That temptation comes from identity, not from engineering need. C++ is a language for abstraction over memory and control flow; iostreams are one library’s opinion about formatting and devices, frozen into a design from an era when extending streambuf was a reasonable way to talk to files. The world moved on: we have memory-mapped I/O, async reactors, structured logging, binary protocols, and security boundaries that do not care about std::ios::hex. Reverse engineers live in that world. They reconstruct packets, not operator<< for std::vector<Employee>.

There is also a maintenance honesty argument. Implementing “enough iostreams to compile hello world” is a trap. Users will next want file streams, stringstreams, manipulators, wide streams, and customization points. Each step pulls locales and more ABI. The only stable positions are full commitment or principled refusal. This PR takes the second position and documents it.

Finally, exclusion clarifies the success metric of NeverC C++: can a researcher model the objects and control flow of a C++ target and compile a POC quickly? Success is not can we run a cppreference iostreams tutorial unchanged. Different products. We choose the first.

---

Scope lock (feature-complete definition)

For this effort, “feature-complete” means:

In scope	Out of scope
ISO C++20 language features needed for research POCs	C++23+
NeverC ABI v1 + neverc_cxx_runtime	System C++ standard library ABI parity
Non-stream std library scaffolds	iostream / stream headers and locales stack
Modules BMI v0 scaffold	Full production module ecosystems (Clang PCM, MSVC IFC interchange)
Coroutines with NeverC runtime helpers	Every QoI optimization of mainstream compilers

Remaining depth work associated with this completion (construction vtables, full array-new cookies, concept subsumption depth, full BMI decl rehydration, promise protocol detail) is treated as in-scope finish work for this feature branch, not as a separate future language edition.

---

Acknowledgments

Thanks to the NeverC maintainers and community for a compiler that is opinionated in the right places. This work is an attempt to meet the project on those terms: practical for security research, explicit about tradeoffs, and unwilling to pretend that every historical C++ library facility deserves a forever tax on the toolchain.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[NeverSightAI]

Thank you for this — genuinely.

I want to start by acknowledging the amount of work that went into it, and the care
you put into the write-up. The argument for why reverse-engineering workflows benefit
from being able to express C++ object models directly is well made, and your reasoning
for keeping iostreams out is one I agree with in principle.

That said, I have to decline this, and I'm sorry I'm only saying so after you've
already invested this much.

The reason is scope, not execution. NeverC is deliberately a C-only compiler and I
intend to keep it that way. Supporting C++ — even a curated subset with its own ABI —
means taking on permanent ownership of name mangling, record layout, exception
handling, template instantiation, and overload resolution. Those are among the
heaviest and most churn-prone parts of any C++ frontend, and carrying them would
change what this project is and how much of it I can keep small, predictable, and
maintainable. That's a complexity cost I'm not willing to take on, independent of how
any particular implementation turns out.

If you're especially interested in C++ tooling for this kind of work, I'd recommend
looking at llvm-msvc (https://github.com/backengineering/llvm-msvc) instead. It's an
LLVM-based toolchain with strong MSVC-oriented C++ support, and it's a much better fit
for that direction than NeverC.

One request for next time, and I'd genuinely welcome it: please open an issue first
for anything of this size. A short proposal describing the scope would have let me
give you this answer before you wrote fourteen thousand lines, which would have been a
much better use of your time. I'm happy to discuss direction early on anything you're
considering.

And if the underlying need is compiling C++ POCs alongside NeverC-built C, I'd be glad
to explore that in an issue. There may be ways to serve it through the plugin API, or
by consuming IR produced by an external frontend, without putting a C++ frontend in
the compiler itself.

Thanks again for taking the project seriously enough to do this.