Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Monday, September 14, 2026

What’s New for C++ Developers in Visual Studio 2026 (18.7 – 18.10)Over the past few months, we have continued shipping monthly Visual Studio 2026 releases, delivering improvements across all stages of the development cycle. In this blog post, we’ll recap everything that changed from version 18.7 through 18.10 (released this month) that is relevant for C++ developers. This includes new tools for maintaining and navigating C++ […] The post What’s New for C++ Developers in Visual Studio 2026 (18.7 – 18.10) appeared first on C++ Team Blog .📝C++ Team Blog
No imageGSoC 2026: Extending Clang API Notes for C++: Overload-Specific Annotations for Functions and MethodsHi! I’m Dominic Stöcker, and during Google Summer of Code 2026 I worked on extending Clang API Notes for C++ with overload-specific annotations for functions and methods. My mentors were Gábor Horváth , John Hui , and Egor Zhdan . This project was originally accepted as a small, 8-week project. As the implementation scope grew, it was expanded to a large, 12-week project. I was interested in this project because it connects Clang’s semantic analysis with Swift interoperability. What made the project especially interesting to me was that a concise user-facing YAML extension had to be connected to Clang’s internal model of declarations, types, overloads, and source-level type spelling. The goal of the project was to let API Notes target individual C++ function and method overloads. The work covered the public YAML design, parsing, binary serialization, declaration lookup, Sema integration, type normalization, diagnostics, and member-function object qualifiers. Background API Notes allow additional information to be attached to declarations without modifying their original source headers. They are used in particular to refine how C, Objective-C, and C++ APIs are exposed to Swift. Previously, an API Notes entry could identify a C++ function or method primarily by name. This is not sufficient when several overloads share that name: struct Widget { void setValue ( int ); void setValue ( double ); }; A name-only entry for setValue applies to the whole overload set, so it cannot assign different annotations to setValue(int) and setValue(double) . The main challenge was therefore not only to select individual overloads, but to do so without changing the behavior of existing name-only API Notes files. Selecting C++ Overloads API Notes are structured according to the kind of declaration they apply to, like Functions , Tags , and Methods . The C++ overload selectors I designed for my project extend the Functions and Methods schemas with an optional Where block that narrows a name-based lookup to a specific C++ overload. Tags : - Name : Widget Methods : - Name : setValue Where : Parameters : - int SwiftName : setIntValue(_:) - Name : setValue Where : Parameters : - double SwiftName : setDoubleValue(_:) This API Notes file uses the Where.Parameters selector to apply separate SwiftName annotations to the int - and double -parameter overloads of setValue . Conceptually, this is equivalent to applying separate Swift name annotations to the two overloads: struct Widget { SWIFT_NAME(setIntValue(_:)) void setValue( int ); SWIFT_NAME(setDoubleValue(_:)) void setValue( double ); }; The same selector is available for overloaded global functions: Functions : - Name : makeWidget Where : Parameters : - int SwiftName : makeWidgetFromInt(_:) - Name : makeWidget Where : Parameters : - double SwiftName : makeWidgetFromDouble(_:) Name-only entries preserve their current behavior: Tags : - Name : Widget Methods : - Name : setValue Availability : nonswift This entry still applies to every method named setValue in Widget . Omitting Where.Parameters leaves the parameter list unconstrained. Adding Where.Parameters narrows the entry to a specific explicit parameter list. An explicitly empty parameter list has a different meaning: Methods : - Name : build Where : Parameters : [] SwiftName : buildWithoutArguments() Where.Parameters: [] selects a declaration with no explicit source parameters. This differs from the name-only case above, which does not constrain parameters at all. The parameter selector describes the complete explicit parameter list, so parameter count and order are significant. Matching C++ Types Matching parameter types requires more than comparing raw strings. Consider a method whose parameter uses a type alias: using Count = int ; struct Counter { void setCount (Count); }; An API Notes author may write a selector using either Count or int . Both are useful, but they do not express exactly the same intent. The implemented lookup first tries the written or sugared type from the declaration. If no matching entry exists, it can fall back to an appropriately desugared representation. This gives an alias-specific selector precedence when both forms exist, while still allowing an underlying-type selector to work as a fallback. The implementation also normalizes spelling differences that should not affect overload identity. This includes insignificant whitespace, spacing around punctuation such as pointers, references, template commas, and template closers, and narrow spelling cases such as unsigned versus unsigned int . Selector-only nullability is stripped during selector formation because API Notes can add or replace nullability independently. This includes nested nullability in pointer, array, and function-pointer type components. Top-level const and volatile also need special handling: void process ( int ); void process ( const int ); These do not declare different C++ overloads. The selector representation therefore removes top-level qualifiers in cases where they do not contribute to overload identity, including the supported by-value and top-level pointer cases. Because top-level const is stripped in this position, the second process declaration is treated as a redeclaration of the first rather than as a separate overload. The goal is not to implement complete semantic type equivalence. Instead, the matching policy preserves useful source-level distinctions while normalizing differences that should not select separate overloads. Matching the Implicit Object Explicit parameters are not enough to distinguish every C++ method overload. Member functions can differ through qualifiers on their implicit object parameter. A common example is operator[] , the subscript operator, with separate const and non- const overloads: struct Buffer { Element & operator []( int ); const Element & operator []( int ) const ; }; Both overloads have the same name and explicit parameter list. Where.Parameters can identify the int parameter, but it cannot distinguish the non- const overload from the const overload by itself. The selector model therefore includes an Object constraint: Tags : - Name : Buffer Methods : - Name : operator[] Where : Parameters : - int Object : Const : false SwiftName : mutableElement(at:) - Name : operator[] Where : Parameters : - int Object : Const : true SwiftName : element(at:) The Object selector describes const , volatile , and reference qualification on the implicit C++ object. The same model can also distinguish lvalue- and rvalue-qualified methods: struct Builder { Result build () & ; Result build () && ; Result build () const & ; }; An API Notes file can combine the empty explicit-parameter selector with Object.Ref to select each ref-qualified overload: Tags : - Name : Builder Methods : - Name : build Where : Parameters : [] Object : Ref : lvalue SwiftName : buildFromLValue() - Name : build Where : Parameters : [] Object : Ref : rvalue SwiftName : buildFromRValue() - Name : build Where : Parameters : [] Object : Const : true Ref : lvalue SwiftName : buildFromConstLValue() Here, Where.Parameters: [] identifies the empty explicit parameter list, while Where.Object.Ref distinguishes lvalue and rvalue receivers. As with Where.Parameters , omitted properties remain unconstrained, while present properties narrow the candidate set. Representing these qualifiers under Object follows the C++ language model more closely than treating the receiver as an ordinary parameter at a special position. These properties belong to the implicit object parameter, not to the method’s explicit parameter list. Static methods and non-member functions do not have an implicit object parameter. Applying an Object constraint to such declarations is therefore invalid and can be diagnosed. Implementation and Results Supporting overload-aware API Notes required changes throughout the existing pipeline: YAML -> API Notes model -> binary serialization -> declaration lookup -> overload-specific filtering -> Sema applies API Notes effects The implementation was split into focused patches. The first changes added YAML parsing and data-model support so that multiple entries with the same declaration name but different selectors could be represented. The next part extended the binary API Notes format . Overload-specific entries must remain distinct when API Notes are compiled and later loaded again. The serialization also preserves the difference between an omitted parameter constraint and an explicitly empty parameter list. The Sema integration preserves legacy name-only lookup while adding overload-specific matching: it first finds API Notes by declaration context and name, then uses the declaration’s explicit parameter types to select the overload-specific entry and apply its effects. Additional work adds diagnostics for malformed, duplicate, and unmatched selectors . The normalization patch refines selector lookup for aliases, nullability, qualifiers, and supported spelling differences, while the object-qualifier patch adds Where.Object matching. A small diagnostics follow-up makes generic -Wapinotes warnings visible for system headers, which matters because API Notes are commonly attached to SDK headers. Tests cover the parser, serialization, Sema lookup, normalization behavior, aliases, default arguments, static methods, zero-parameter declarations, and object-qualified member functions. The result is an overload-aware selector model that supports both global functions and C++ methods while preserving existing API Notes behavior. Future Template Design The overload selector model only applies to concrete methods and functions. As part of my project, I also explored how the overload selector model could be extended to support C++ templates in the future. Function template matching is not currently implemented, but this design work helped identify which parts of the selector model should remain extensible. Ordinary Where.Parameters matching works for concrete function parameter types. Templates add several harder questions. One selector might need to identify a function template or one of its specializations, such as f . Another selector might need to match an ordinary function overload whose parameter type contains a class template specialization or dependent template parameter. For example, dependent types can refer to template parameters directly, through nested dependent names, or as part of a larger type: template typename T > void f( const T & ); template typename Container > void f( const typename Container :: value_type & ); template typename Key, typename Value > void f( const std :: pair Key, Value > & ); Relying only on source names such as T , Container , Key , or Value would be fragile because template parameter names can differ across redeclarations and library implementations. The design notes therefore explored structural template-parameter identity using depth and index, matching concrete template arguments for specializations such as f , and a possible mapping from stable template-parameter identities to readable names so dependent types such as const T & can still be written clearly. One possible direction was to assign stable identities to template parameters in API Notes, using depth and index, and then map those identities to readable local names used in dependent parameter spellings such as const T & . This would avoid relying on redeclaration-local source names while still keeping API Notes readable. The template design document contains illustrative future syntax for these ideas. That syntax is rejected by the current API Notes implementation. Reflections This project gave me practical experience working across several parts of Clang, from YAML parsing and API Notes serialization to declaration lookup, type representation, diagnostics, and Sema integration. One of the main lessons was that preserving existing API Notes behavior was as important as adding the new selector support. Name-only notes still need to match as they did before, while overload-specific notes need clear rules for matching and diagnostics. It also taught me how valuable small, focused upstream patches are: splitting the parser, serialization, Sema, diagnostics, normalization, and object-qualifier work made each part easier to review, test, and revise. The project also made me more interested in continuing to work on Clang, especially in areas where C++ language support and Swift interoperability meet. Acknowledgements I would like to thank my mentors, Gábor Horváth, John Hui, and Egor Zhdan, for their thoughtful reviews, engaging design discussions, and support throughout Google Summer of Code. Their feedback helped preserve compatibility with existing API Notes while extending the model to support overload matching, type normalization, and C++ object qualifiers. Links GSoC final report Project design document Development diary Development repository Patch series: Parse Where.Parameters for C++ functions and methods Serialize overload parameter selectors Apply overload-aware API Notes in Sema Add diagnostics and integration coverage Normalize parameter types during selector lookup Match C++ member-function object qualifiers Show API Notes warnings in system headers Template-matching design notes Template specialization selector design branch📝The LLVM Project Blog

If this page is useful, please consider donating a coffee

Sunday, September 13, 2026

Saturday, September 12, 2026

lld 23 ELF changesLLVM 23.1 has been released. As usual, I maintain lld/ELF and as volunteer work have added some notes to https://github.com/llvm/llvm-project/blob/release/23.x/lld/docs/ReleaseNotes.rst . Like last time, I used Claude Code to summarize git log llvmorg-23-init..origin/release/23.x -- lld/ELF , excluding changes cherry-picked into 22.x ( git rev-list llvmorg-23-init..llvmorg-22.1.8 -- lld ), and then edited the draft. This was a busy cycle: 141 commits landed in lld/ELF between the branch point (2026-01-13) and 23.1.0-rc1 (2026-07-16), compared with 72 in the 22 cycle. Much of the increase is performance work, which I described in Recent lld/ELF performance improvements . lld 23 is the first release that ships all of it.📝MaskRay

Friday, September 11, 2026

Thursday, September 10, 2026

MSVC C++23: constexpr cmath with LLVM LibcProposal P0533R9 made numerous math functions in the standard library compile-time evaluable in C++23. Implementing the feature required a good bit of time and effort, but MSVC is preparing its experimental implementation for the 14.52 build tools (compiler version 19.52)! We are still refining the feature, so expect the dust to settle only when this […] The post MSVC C++23: constexpr cmath with LLVM Libc appeared first on C++ Team Blog .📝C++ Team Blog
Join Us at the Zephyr Project Meetup in AmsterdamRegister for the Meetup On September 15, the Zephyr community is coming together for an in-person meetup at the JetBrains office in Amsterdam. The Zephyr Project is an open-source collaboration project hosted by the Linux Foundation. Its community brings together developers, users, silicon vendors, device manufacturers, and software companies to build a small, scalable real-time […]📝CLion : A Cross-Platform IDE for C and C++ | The JetBrains Blog

Wednesday, September 9, 2026

MSVC Build Tools Preview updates – September 2026The MSVC Build Tools Preview is updated regularly with the latest features and fixes from the MSVC development team. This post covers updates from the past month, currently targeting the v14.52 release. This encompasses changes across the compiler frontend, backend, linker, standard library, and related tools. Although you can acquire the MSVC Build Tools Preview […] The post MSVC Build Tools Preview updates – September 2026 appeared first on C++ Team Blog .📝C++ Team Blog
Introducing any2bazel - an OSS tool for agent-driven migrations to BazelIntroducing any2bazel - an OSS tool for agent-driven migrations to Bazel Back in June I was sitting on a train to Zurich. The plan was to meet colleagues and work together on figuringout how to migrate CMake projects to Bazel. I was looking forward to chatting with my colleagues in person,but I was not optimistic about the migration process.Truth be told, I was expecting to spend the week walking through the problems parsing the custom CMake languageand CMake being Turing complete, maybe even look at a few concrete cases like generated files and configurationflags, finally conclude it couldn't be done, and return home with not much to show. Oh boy was I wrong.📝EngFlow Blog

Tuesday, September 8, 2026

Security advisory: CVE-2026-11573 Uncontrolled recursion in QDomDocument serializationUpdated 11 September 2026: the affected version range in this advisory has been corrected. It originally read "from 6.7.0 to 6.8.1". Further source review established that the recursive serialization code has been present since Qt 2.2.0, so all Qt versions before the fixed releases listed below are affected. The CVE record has been updated accordingly. The severity assessment and CVSS score are unchanged. An uncontrolled recursion (CWE-674) vulnerability in the Qt QDomDocument serialization path of the Qt XML module (QtXml, qtbase) has been discovered and has been assigned the CVE id CVE-2026-11573 . The affected code is reachable through QDomDocument::toByteArray() (Qt 4.0 and later), QDomDocument::toString() , QDomDocument::toCString() , QDomNode::save() , and operator .📝Qt Blog
Qt Design Studio 4.8.3 ReleasedQt Design Studio 4.8.3 Is Here! Qt Design Studio 4.8.3 is a maintenance release that builds on foundations of 4.8.2: a round of improvements to the Figma design workflow from both ends of the pipeline, fixes to property editing for Qt for MCUs projects, and a refreshed set of AI models. Qt Bridge The Qt Bridge importer now retains the settings from your last import, remembering both the import options and the path, so bringing in an updated design no longer means re-entering the target directory and re-picking your options every time. Alongside that, a handful of correctness fixes improve the QML that comes out of an import: colors are no longer added to plain Items, master components get proper default values for aliasing, inner attached property overrides are no longer propagated since QML does not support this, and imported UIID names no longer get an _instance suffix appended.📝Qt Blog
Robotics with Conan: consuming ROS as a regular packageWe know that many of you use Conan for C++ development in robotics, and that some of you have probably considered adding ROS support to those projects at some point. That is usually where Conan and ROS stop fitting together. Your control, perception or planning code is written in C++ and managed with Conan, while ROS is a layer on top of it that has to be dealt with separately, installed system-wide with apt , rosdep , brew or choco on every developer machine and every CI agent. If you have not worked with it, ROS (Robot Operating System) is a framework for building robotics applications: a large set of C++ and Python libraries and tools, together with the conventions that let components written by different teams work with each other. Your components run as processes that exchange data through a publish/subscribe layer built on top of DDS, using standard message types for sensor data, geometry and coordinate transforms. That universality is where its power comes from : once your code speaks those interfaces, it can be combined with the drivers, algorithms, robot models and tools that the rest of the ecosystem already publishes, or with those of the partners you work with. For some months now we have been experimenting with conan-io/ros-conan , a set of recipes that build the Kilted ROS distribution from source and expose it as a regular Conan package for Linux, macOS and Windows. The idea we wanted to explore is whether adding ROS support to a C++ project already using Conan could be one more requires , instead of a separate installation with its own workflow. A conan install puts the ROS installation in your cache, and from there you require and consume it like any other package. It is the other direction from the colcon integration we described in 2024 , where Conan packages are consumed transparently inside a ROS workspace: here ROS itself enters the usual C++ and Conan flow. We would like to emphasize that this is an experiment rather than a finished feature . The recipes are not finished, there are no prebuilt binaries for them and they are not even included in Conan Center. This is exploratory work to propose a new approach to developing robotic applications with ROS. Download the video The pose_estimation example: a ROS node that tracks human pose from an image input, with ros-kilted , opencv and tensorflow-lite resolved in a single dependency graph What consuming it looks like By exploring the folder of the example shown above: cd ros-conan/examples/pose_estimation tree . ├── assets │ ├── dancing.mp4 │ ├── dancing.png │ ├── lite-model_movenet_singlepose_lightning_tflite_float16_4.tflite │ └── output.gif ├── ci_test_example.py ├── CMakeLists.txt ├── conanfile.txt ├── readme.md └── src └── pose-estimation.cpp You can check that ROS shows up as one more requires : conanfile.txt [requires] ros-kilted/2026.06.17 tensorflow-lite/2.15.0 opencv/4.12.0 [generators] CMakeToolchain CMakeDeps [layout] cmake_layout On the CMake side, ROS packages are located with their usual find_package() calls. The recipe puts the ROS installation on CMAKE_PREFIX_PATH , so the config files that ROS itself installs are the ones being used: CMakeLists.txt find_package ( rclcpp REQUIRED ) find_package ( geometry_msgs REQUIRED ) find_package ( visualization_msgs REQUIRED ) find_package ( tensorflowlite REQUIRED ) find_package ( OpenCV REQUIRED ) add_executable ( pose-estimation src/pose-estimation.cpp ) target_link_libraries ( pose-estimation PRIVATE rclcpp::rclcpp ${ geometry_msgs_TARGETS } ${ visualization_msgs_TARGETS } tensorflow::tensorflowlite opencv::opencv ) ros-kilted is more than the C++ client library. The recipe packages the distribution, so besides rclcpp you get the standard message packages such as geometry_msgs or sensor_msgs and, depending on the variant you pick, coordinate transforms with tf2 or the visualization tools. The variant recipe option ranges from core (default) to desktop and decides how much of ROS gets built. The recipes are not in Conan Center, so ros-kilted is resolved by cloning the repository next to your project and adding it as a local-recipes-index remote. That clone is also where the profiles/ros profile comes from. The two commands for that are in the README : git clone https://github.com/conan-io/ros-conan.git conan remote add ros-conan ./ros-conan --type = local-recipes-index Then the usual install and build sequence of any Conan project: conan install --profile = ros-conan/profiles/ros --build = missing cmake --preset conan-release cmake --build --preset conan-release Note : on Windows, building ROS produces deep directory trees that exceed the default 260-character path limit. Enable long paths before running conan install . One good thing about this approach is that there is no need to bring all the usual ROS tooling and workspace conventions into your C++ project. The application stays a plain CMake project that happens to require ROS. For a codebase where ROS is one layer of a larger C++ product, we think that is a reasonable place to be, but we would like to hear whether it holds up in a real project. What this brings These are the advantages we see in the approach, and the reason we consider this work worth sharing: One dependency graph. ROS is resolved together with the rest of your requirements, so Conan can detect version conflicts between the robotics libraries and everything else. No system-wide install. ROS lives in the Conan cache, so different versions can coexist on the same machine and each project activates the one it needs. The same tooling as the rest of your dependencies. Profiles, options, lockfiles, remotes and CI pipelines apply to ROS as they do to any other package, with the same commands on the three platforms. Composable with Conan Center. Robotics applications often need opencv , eigen or tensorflow-lite among others, and those come from the same graph, with no glue in between. The ROS tools still work as usual If you are already familiar with ROS, the ros-kilted recipe brings a couple of conveniences: the whole installation arrives with a single conan install , and the ros2 commands can be run without sourcing anything by hand. Everything else behaves as the official tutorials describe. Here is turtlesim , the small simulator used to introduce ROS, launched straight from the installation Conan provides. It is part of the desktop variant, so that is the one to select. Using a conanfile.txt , you can declare the desktop variant: [requires] ros-kilted/2026.06.17 [options] ros-kilted/*: variant = desktop And then execute ros2 directly from the conan run : conan run "ros2 run turtlesim turtlesim_node" --profile = ros-conan/profiles/ros --build = missing turtlesim launched from a Conan-provided ROS installation We would like to know what you think Now that we have introduced this way of installing ROS with Conan, we would like to know if this approach makes sense to you. We encourage you to try the examples in the conan-io/ros-conan repository (if you have not already) and tell us what you think by opening an issue on GitHub . Any feedback is greatly appreciated! We will also be at ROSCon Global 2026 in Toronto . If you are attending, we would be happy to talk about this in person. Hope to see you there!📝Conan C/C++ Package Manager Blog