Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Thursday, September 24, 2026

Why Tests Became the Product: A Conversation with Titus Winters | EngFlowWhy Tests Became the Product: A Conversation with Titus Winters A conversation with Titus Winters · Notes From The Fleet series Watch the full interview I sat down with Titus Winters to talk about developer experience and infrastructure at scale. Titus co-wrote Software Engineering at Google ; he is now a Senior Principal Scientist at Adobe. I expected a conversation about build systems. What I got was a line I've been thinking about ever since: "The question is not what can you build with an incredibly fast, 80% accurate tool. It's what can't you build with an infinite army of incredibly fast, 80% accurate tools." An infinite army of 80% accurate tools. That army doesn't have a code generation problem. It has a verification problem. Whether it helps you or buries you depends on the systems that check, integrate, and maintain everything it produces. [![Titus Winters interview](/images/2026-titus-winters/titus-interview.png)](https://youtu.be/YyqgNpNQJwQ?si=FQdLSQxUJXHmn5qz){ class="img-fluid w-100"} Titus Winters on the shift from code generation to verification in the AI era📝EngFlow Blog

If this page is useful, please consider donating a coffee

Wednesday, September 23, 2026

Canvas2D: WatchUI DemoIn the previous blog post I introduced Canvas2D , the new QML item in Qt 6.12 that lets you paint with JavaScript using the GPU through Qt Canvas Painter. That post was about the API: what it is, how it compares to Qt Quick Canvas and to the QCanvasPainter C++ API , and how fast it is. But that post might have left someone wondering what a real UI built with it could actually look like. So, while testing Canvas2D (and QQEM) in preparation for the Qt 6.12.0 release, I spent a few days building a demo application to give some ideas. WatchUI is a smartwatch demo with six swipeable views, running on a 3D watch model. This is based on the smartwatch demo that was built a while back for the Qt 6.5 release . But the content of the watch screen has been reimplemented using not just QQEM effects but also Canvas2D. The demo looks like this:📝Qt Blog
Hot Reload in Qt 6.12QML Preview We've had a thing called "QML Preview" for a number of years now. You can be forgiven for not having noticed. It's well hidden deep in the guts of Qt Design Studio where it's quietly doing what it does: it runs your design through the qml tool and gets notified when you change some file. Then it re-loads the currently visible scene, without re-starting the process, making your changes visible. This way you get faster turnaround when prototyping different designs.📝Qt Blog
⬢ Distrobox: An In-depth Guide for Developers - Part 1Distrobox gives developers a fast, practical way to work across Linux distributions without the setup time and resource overhead of full virtual machines. This in-depth guide explains how Distrobox builds on OCI containers and tools such as Podman or Docker to create tightly integrated development environments—with access to your home directory, graphical sessions, devices, and host tooling. Learn why it is useful for reproducing distro-specific bugs, testing software on multiple platforms, accessing alternative package repositories, and combining a stable host OS with flexible, disposable userlands.📝KDAB

Tuesday, September 22, 2026

Faster C++ code intelligence for Copilot CLI with Whole Codebase IndexingC++ repositories can contain millions of lines of code spread across deeply connected source files and headers. Without a reusable index, navigating to definitions, finding references, or searching for symbols may require portions of that information to be analyzed again as you move through the repository. C++ code intelligence in GitHub Copilot CLI is now […] The post Faster C++ code intelligence for Copilot CLI with Whole Codebase Indexing appeared first on C++ Team Blog .📝C++ Team Blog

Monday, September 21, 2026

No imageGSoC 2026: Improving HLSL Support in clangdGSoC 2026: Improving HLSL Support in clangd HLSL (High-Level Shading Language) is a C++-like language used for GPU shader programming. Clang already parses HLSL and represents many of its constructs in the AST. clangd , however, reuses its C/C++ infrastructure to provide IDE features such as hover, code completion, diagnostics, and navigation. Clang may fully understand an HLSL construct, while clangd does not necessarily know how to expose that information to the user. For example, HLSL has language-specific constructs such as semantic annotations, resource bindings, out / inout parameters, shader attributes, and vector and matrix swizzles. These constructs do not always have direct equivalents in standard C++, so the existing clangd infrastructure does not automatically provide the expected editor experience. The goal of my Google Summer of Code 2026 project was to identify these gaps and improve HLSL support in clangd . I first wanted to understand the current state of HLSL support, identify where the problems were coming from, and determine which solutions would fit best into the existing Clang and clangd architecture. The project followed this process: Gap Analysis | v Investigation | v Implementation Ideas | v RFC | v Community Feedback | v GitHub Issues | v Pull Requests Finding the Gaps The first phase of the project was a to do a gap analysis. I created isolated HLSL test cases covering different categories of language constructs and tested them using several clangd features: hover, code completion, go-to-definition, and diagnostics. When the behavior was unclear, I also inspected Clang’s AST to determine whether the required information was already available to clangd. The goal was to distinguish between different kinds of problems. Some constructs were already represented correctly in the AST but were not exposed by clangd. Others involved configuration, while some problems originated earlier in the compiler pipeline. This distinction was important because the solution depends heavily on where the gap actually exists. For example, if Clang already has all the information needed in the AST, adding another HLSL-specific parser or compiler feature would be unnecessary. Instead, the appropriate solution may be to extend existing clangd infrastructure. Full writeup: Gap Analysis From Gaps to Solutions After identifying the gaps, I investigated possible implementation approaches for each one. For every issue, I looked at: where the relevant information was represented in Clang; how clangd currently handled similar C/C++ constructs; why the existing infrastructure did not work for HLSL; whether the problem should be fixed in Clang or clangd; and what possible implementation approaches were available. I documented these ideas before starting the implementation so the design could be discussed with my mentors and the LLVM community. Full writeup: Implementation Ideas RFC and Community Feedback After discussing the implementation ideas with my mentors, I consolidated the proposed solutions into an RFC and submitted it to the LLVM Discourse community. RFC: Improving HLSL Support in clangd The RFC described the expected behavior, the observed gap, the root cause, and the proposed solution for each issue. The discussion with the LLVM and DirectX communities was an important part of the project. Some of my initial ideas were refined based on the feedback I received. For example, semantic completion after : initially considered suggesting HLSL semantics unconditionally. The discussion highlighted that not every identifier in that context is necessarily a semantic, so the implementation was refined to make semantic suggestions dependent on the typed prefix. Another example was vector and matrix swizzle completion. The discussion raised concerns about automatically triggering completion after every . , which could become distracting during normal editing. The final implementation therefore made HLSL swizzle completion configurable. From RFC to Issues and Pull Requests After the RFC discussion, I created a separate GitHub issue for each implementation item. Each issue documented the expected behavior, the current behavior, the root cause, and the proposed solution. The 11 issues were divided into two main areas. Hover Semantic annotations such as SV_Target and SV_Position - issue #214808 / PR #217725 Loop and branch control attributes such as [unroll] and [loop] - issue #214067 / PR #214318 out and inout parameter qualifiers - issue #214071 / PR #214883 Vector swizzle and matrix element access - issue #212612 / PR #212741 RootSignature hover - issue #214790 / PR #214955 register(...) hover ranges - issue #212749 / PR #212881 Code Completion Attribute completion inside [...] - issue #214792 / PR #215353 register(...) completion - issue #214798 / Draft PR (Depend on PR not merged yet) HLSL annotations after : - issue #214801 / Draft PR (Depend on PR not merged yet) Vector swizzle completion - issue #214804 / PR #217381 Matrix swizzle completion - issue #214805 / Draft PR (Depend on PR not merged yet) Each issue was then implemented as an independent pull request, making the changes easier to review and upstream. All PRs: link Some Examples One of the most interesting parts of the project was discovering that HLSL constructs are sometimes represented internally in ways that are different from how users wrote them. For example, HLSL out and inout parameters are lowered internally to C++ reference types. Given: void ApplyFog( out float4 color, inout float depth); hovering over color previously exposed an internal representation such as float &__restrict instead of the HLSL type out float4 . The solution was to add a getHLSLParamTypeAsWritten() helper that allows clangd to recover the original HLSL type for display, independently of how the parameter is represented internally. Another example was HLSL semantic annotations. Constructs such as: float4 main() : SV_Target were already represented by Clang, but hover did not display the semantic spelling correctly. Investigating the AST showed that the necessary information existed, but the relevant HLSL attribute did not provide the spelling expected by the generic hover infrastructure. This allowed the problem to be fixed at the appropriate layer rather than by adding an HLSL-specific workaround to the hover implementation. Multiple Entry Points In addition to the original gaps, I investigated a larger architectural problem involving HLSL files containing multiple shader entry points. A single HLSL file can contain multiple entry points, for example: [shader( "vertex" )] void VSMain(...) { ... } [shader( "pixel" )] void PSMain(...) { ... } This creates a challenge for clangd, which traditionally works with a single active compilation context for a file. Different HLSL entry points can require different compilation contexts, especially in legacy HLSL, where the shader stage and entry point are specified through compiler flags rather than source annotations. Modern HLSL For modern HLSL, entry points can be annotated directly in the source, using [shader("vertex")] , [shader("pixel")] , and so on. In this case, I found that using an HLSL library target allows Clang to build a single AST containing the different entry points. I implemented a fallback for HLSL files without an available compilation command that uses the library target automatically. This provides a generic compilation context that works well for modern HLSL files containing multiple entry points. Legacy HLSL The legacy case is more difficult. When the entry point is selected through compiler flags, different entry points may require different compilation commands, and clangd cannot simply use one compilation command and expect all entry points to be represented correctly. I investigated possible approaches and built a prototype for explicitly switching the active compilation context. The prototype allows clangd to discover the entry points available in a file and switch between their compilation contexts without requiring the user to close and reopen the file. The server-side mechanism was validated end to end using LSP communication. Full writeup: Multiple Entry Point Investigation This work is not yet a complete upstream solution, but it provides a foundation for continuing the work after GSoC. Future Work The main remaining area of work is the legacy multiple-entry-point problem. The prototype still needs to be developed into an upstreamable solution and paired with client-side UX for selecting the active entry point. The investigation already provides pieces that can be reused in future work: entry-point discovery; compilation-context switching; the HLSL library-mode fallback; the investigation of clangd’s compilation database behavior; and the LSP prototype used to validate the approach. There are also smaller follow-up opportunities, such as richer RootSignature hover information, a default files.associations entry for .hlsl in vscode-clangd , and additional HLSL-specific configuration improvements. What I’ve Learned Before Google Summer of Code, I had some experience working with LLVM, but I had never worked on clangd or HLSL support. One of the most valuable things I learned was how to investigate a compiler tooling problem from the user’s perspective and trace it back to its root cause. During the project, I often had to move between different layers of the compiler, from the LSP behavior in clangd, through its AST handling, down to parsing and semantic analysis in Clang. I also learned how important it is to understand the existing architecture before implementing a fix. In several cases, the information required to support an HLSL feature was already available in Clang, and the right solution was to make existing infrastructure aware of it rather than introducing a separate HLSL-specific implementation. The upstreaming process was another major part of the learning experience. Writing an RFC, discussing design alternatives with the LLVM community, incorporating feedback, creating focused issues, and eventually submitting reviewable pull requests taught me a lot about how large open-source projects are developed. Finally, investigating multiple entry points showed me that not every problem can be solved by fixing a single missing feature. Some problems require understanding the interaction between the compiler, clangd, the compilation database, and the LSP itself. Overall, GSoC gave me much more confidence navigating a large compiler codebase, debugging problems across different layers of the compiler, and contributing changes to a project as large as LLVM. Acknowledgments I would like to thank my mentors, Finn Plummer and Ashley Coleman, for their guidance and support throughout this project. They always made time to talk to me, discuss my progress, answer my questions, and help me work through the challenges I encountered. I am grateful for all the feedback they gave on my ideas, and for taking the time to explain things, listen to my proposals, and help me find a way forward whenever I was unsure about something. Working with them was one of the most valuable parts of this experience, and I learned a great deal from the way they approached problems. I would also like to thank the LLVM and DirectX communities for the discussions and feedback on the RFC and implementation ideas. Their input was an important part of refining the proposed solutions and understanding how these features should fit into clangd’s existing architecture.📝The LLVM Project Blog

Sunday, September 20, 2026

Linker I/O tricks and their downsidesmold and wild enable several tricks by default that other linkers don't do. This post looks at three of them: overwrite an existing output file in place instead of creating a new file fork a child to do the link, so that the parent can exit before the child releases its memory ask the kernel for transparent huge pages Each saves a few percent of wall time in an edit-relink loop. Each also breaks an assumption that build systems, debuggers, and profilers make about a process. I measured what they save and what they break. Setup: Linux 6.18, i7-14700K (28 threads), ext4 on a SATA SSD, transparent huge pages enabled=always . GNU ld 2.47, gold 2.47, LLD 23, mold 2.42.1 (TODO: I used the Rust port under development; check against the C++ release), wild at commit 47cc8e8e.📝MaskRay

Saturday, September 19, 2026

Friday, September 18, 2026