# codegen

Published articles for codegen.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## What's New in Apollo Client 4.3

DevFeed: [What's New in Apollo Client 4.3](<https://devfeed.tech/articles/what-s-new-in-apollo-client-4-3-32028.md>)

Original publisher: [Read original article](<https://www.apollographql.com/blog/whats-new-in-apollo-client-4-3>)

Author: Jerel Miller

Published: 2026-09-15T12:01:05Z

Content type: release

Language: en

Sources: [Apollo Blog](<https://devfeed.tech/sources/apollo-blog.md>)

Topics: [apollo-client](<https://devfeed.tech/topics/apollo-client.md>), [GraphQL](<https://devfeed.tech/topics/graphql.md>), [TypeScript](<https://devfeed.tech/topics/typescript.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [Code generation](<https://devfeed.tech/topics/code-generation.md>)

Tags: [apollo-client](<https://devfeed.tech/tags/apollo-client.md>), [cache](<https://devfeed.tech/tags/cache.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [graphql](<https://devfeed.tech/tags/graphql.md>), [native](<https://devfeed.tech/tags/native.md>), [typescript](<https://devfeed.tech/tags/typescript.md>)

### AI overview

Apollo Client 4.3 adds native custom scalar support, type-safe cache access, and improved TypeScript handling for incremental GraphQL data. The release also updates generated types and data-state narrowing for deferred fields.

### Source excerpt

Apollo Client 4.3 is here: native custom scalar support, type-safe cache access, and more consistent @defer and @stream behavior. See what's new and upgrade today.

## Optimizing LLVM's bump allocator

DevFeed: [Optimizing LLVM's bump allocator](<https://devfeed.tech/articles/optimizing-llvm-s-bump-allocator-31134.md>)

Original publisher: [Read original article](<https://maskray.me/blog/optimizing-llvm-bump-allocator>)

Published: 2026-06-28T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [clang](<https://devfeed.tech/topics/clang.md>)

Tags: [changes](<https://devfeed.tech/tags/changes.md>), [clang](<https://devfeed.tech/tags/clang.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [debug](<https://devfeed.tech/tags/debug.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [memory](<https://devfeed.tech/tags/memory.md>), [optimizing](<https://devfeed.tech/tags/optimizing.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### AI overview

This article explains three recent changes that optimize LLVM's BumpPtrAllocator: avoiding unnecessary realignment, using a sentinel to eliminate a null check, and removing per-allocation accounting from the hot path. It also discusses alignment, typed allocation, incomplete types, and ABI considerations.

### Source excerpt

BumpPtrAllocator is LLVM's bump allocator (arena allocator): each allocation bumps a pointer within a slab, and everything is freed at once when the allocator dies. It backs Clang's ASTContext, lld's make<T> object pools, TableGen records, and many other arenas. Here is the fast path before three recent changes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 __attribute__((returns_nonnull)) void *Allocate(size_t Size, Align Alignment) { BytesAllocated += Size; // (3) accounting RMW uintptr_t AlignedPtr = alignAddr(CurPtr, Alignment); // (1) always realign size_t SizeToAllocate = Size; #if LLVM_ADDRESS_SANITIZER_BUILD SizeToAllocate += RedZoneSize; #endif uintptr_t AllocEndPtr = AlignedPtr + SizeToAllocate; if (LLVM_LIKELY(AllocEndPtr <= uintptr_t(End) && CurPtr != nullptr)) { // (2) bound + null check CurPtr = reinterpret_cast<char *>(AllocEndPtr); ... return reinterpret_cast<char *>(AlignedPtr); } return AllocateSlow(Size, SizeToAllocate, Alignment); }

## A deep dive into SmallVector::push\_back

DevFeed: [A deep dive into SmallVector::push\_back](<https://devfeed.tech/articles/a-deep-dive-into-smallvector-push-back-31123.md>)

Original publisher: [Read original article](<https://maskray.me/blog/a-deep-dive-into-smallvector-push-back>)

Published: 2026-06-27T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [clang](<https://devfeed.tech/topics/clang.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [gcc](<https://devfeed.tech/topics/gcc.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [clang](<https://devfeed.tech/tags/clang.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### AI overview

This article examines an LLVM SmallVector::push_back optimization for approximately trivially copyable element types. It explains how tail-calling the slow growth path reduces the fast path from 14 to 7 instructions and avoids callee-saved registers, while noting tradeoffs for out-of-line calls and overall build size.

### Source excerpt

tl;dr This blog post describes a recent SmallVector::push_back optimization for approximately trivially copyable element types. SmallVector is LLVM's most-used container, and push_back its hot operation. For the trivially-copyable specialization the fast path should be fast. 1 2 3 #include <llvm/ADT/SmallVector.h> void f(llvm::SmallVectorImpl<int> &v, int x) { v.push_back(x); } clang -S --target=x86_64 -O2 -DNDEBUG a.cc generates: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 push rbp # callee-saved spills + a stack realignment, push rbx # all on the fast path push rax mov eax, [rdi + 8] # size cmp eax, [rdi + 12] # vs capacity jae .Lgrow .Lstore: # reached from the fast path AND from .Lgrow mov rcx, [rdi] mov [rcx + rax*4], esi inc dword ptr [rdi + 8] add rsp, 8 pop rbx pop rbp ret .Lgrow: mov rbx, rdi # keep `this`/`x` alive across the call mov ebp, esi call SmallVectorBase<unsigned>::grow_pod ... jmp .Lstore

## How Claude Code's Source Map Was Shipped and Rebuilt by the Community

DevFeed: [How Claude Code's Source Map Was Shipped and Rebuilt by the Community](<https://devfeed.tech/articles/diving-into-claude-code-s-source-code-leak-39083.md>)

Original publisher: [Read original article](<https://read.engineerscodex.com/p/diving-into-claude-codes-source-code>)

Author: Engineer's Codex

Published: 2026-04-01T06:25:24Z

Content type: article

Language: en

Sources: [Engineer's Codex](<https://devfeed.tech/sources/engineer-s-codex.md>)

Topics: [Claude Code](<https://devfeed.tech/topics/claude-code.md>), [anthropic](<https://devfeed.tech/topics/anthropic.md>), [Code generation](<https://devfeed.tech/topics/code-generation.md>), [GitHub](<https://devfeed.tech/topics/github.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [Code review](<https://devfeed.tech/topics/code-review.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [anthropic](<https://devfeed.tech/tags/anthropic.md>), [claude-code](<https://devfeed.tech/tags/claude-code.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [github](<https://devfeed.tech/tags/github.md>), [leak](<https://devfeed.tech/tags/leak.md>), [npm](<https://devfeed.tech/tags/npm.md>), [openai](<https://devfeed.tech/tags/openai.md>), [post-mortems](<https://devfeed.tech/tags/post-mortems.md>)

### AI overview

The article examines how Anthropic accidentally included a sourcemap in a Claude Code npm package, how the exposed code was mirrored and ported to other languages, and the resulting copyright questions around AI-assisted clean-room rebuilding.

### Source excerpt

Engineer's Codex is a publication about real-world software engineering.

## Bit-field layout

DevFeed: [Bit-field layout](<https://devfeed.tech/articles/bit-field-layout-31124.md>)

Original publisher: [Read original article](<https://maskray.me/blog/bit-field-layout>)

Published: 2026-02-22T08:00:00Z

Content type: tutorial

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [implementation](<https://devfeed.tech/topics/implementation.md>), [C](<https://devfeed.tech/topics/c.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [clang](<https://devfeed.tech/topics/clang.md>), [gcc](<https://devfeed.tech/topics/gcc.md>), [LLVM](<https://devfeed.tech/topics/llvm.md>), [MSVC](<https://devfeed.tech/topics/msvc.md>)

Tags: [c](<https://devfeed.tech/tags/c.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [clang](<https://devfeed.tech/tags/clang.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [compiler-optimization](<https://devfeed.tech/tags/compiler-optimization.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [msvc](<https://devfeed.tech/tags/msvc.md>)

### AI overview

This article explains how C and C++ bit-field layout is implementation-defined and governed primarily by platform ABIs. It distinguishes ABI-defined storage layout from compiler code generation, focusing on the Itanium ABI and describing differences in the Microsoft ABI.

### Source excerpt

The C and C++ standards leave nearly every detail to the implementation. C23 §6.7.3.2: An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified C++ is also terse -- [class.bit]p1: Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit.

## Manually parsing JSON with Moshi

DevFeed: [Manually parsing JSON with Moshi](<https://devfeed.tech/articles/manually-parsing-json-with-moshi-38544.md>)

Original publisher: [Read original article](<https://msfjarvis.dev/posts/manually-parsing-json-with-moshi/>)

Author: Harsh Shandilya

Published: 2020-12-21T06:30:00Z

Content type: tutorial

Language: en

Sources: [Posts on Harsh Shandilya](<https://devfeed.tech/sources/posts-on-harsh-shandilya.md>)

Topics: [JSON](<https://devfeed.tech/topics/json.md>), [Parsing](<https://devfeed.tech/topics/parsing.md>), [Library](<https://devfeed.tech/topics/library.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Java](<https://devfeed.tech/topics/java.md>), [Android](<https://devfeed.tech/topics/android.md>)

Tags: [adapter](<https://devfeed.tech/tags/adapter.md>), [annotation](<https://devfeed.tech/tags/annotation.md>), [codegen](<https://devfeed.tech/tags/codegen.md>), [crash](<https://devfeed.tech/tags/crash.md>), [database](<https://devfeed.tech/tags/database.md>), [json](<https://devfeed.tech/tags/json.md>), [json-parsing](<https://devfeed.tech/tags/json-parsing.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [library](<https://devfeed.tech/tags/library.md>), [moshi](<https://devfeed.tech/tags/moshi.md>), [moshi-read-json-from-file](<https://devfeed.tech/tags/moshi-read-json-from-file.md>), [parsing](<https://devfeed.tech/tags/parsing.md>), [performance](<https://devfeed.tech/tags/performance.md>), [schema](<https://devfeed.tech/tags/schema.md>)

### AI overview

A tutorial on manually parsing JSON with Moshi, covering adapters, reflection-based parsing, and kapt-backed code generation for Java and Kotlin classes on the JVM and Android.

### Source excerpt

Moshi is a fast and powerful JSON parsing library for the JVM and Android. Today we look into manually parsing JSON to and from Java/Kotlin classes