Add ReSharper C++ as a frontend?

[Smertig]

First, thanks for cppstat, it's really great and illustrative. I use it a lot!

I work on the CLion team at JetBrains, and we have our own C++ language engine (called ReSharper C++, or simply R++), which is used in CLion and Rider, and is also available as a plugin for Visual Studio.

It is very similar to a compiler frontend, because it drives all the language support inside the IDE. It has its own preprocessor, parser, name lookup, type system with template instantiation, constexpr engine, and more, all written from scratch.

My suggestion: add R++ as one more column, in a separate group if that fits better, with per-version data that we fill and keep current.

Why it might fit your website: I believe it would be nice for users to understand not only which compilers support one or another core language feature, but also how ready the tooling is for it. As an example, the only compiler supporting C++26 reflection is GCC 16, and ReSharper C++ has supported it in CLion and Rider since v2026.2.

There are not so many language engines that power C++ support in an IDE. Basically clangd (LSP, on par with Clang), EDG (it powers Visual Studio's IntelliSense, and does not always match MSVC in support), and R++. IMO it would be useful to have EDG on your website as well, like cppreference does at https://en.cppreference.com/cpp/compiler_support, but that is not up to me.

Questions:

1. Do you want it at all? If a proprietary frontend does not fit the site, that is a fair answer.
2. Where should it go? R++ is not a toolchain. A new group such as "Frontends", or just one more column?
3. There are a lot of library features. R++ implements no standard library, so those rows belong to the toolchain and not to us. Does a third state sound reasonable, say (n/a), rendered gray, with an explanation on hover?
4. Our version numbers are of the form 2026.2, which is a bit longer than just 12.3. Is that fine?
5. Most features have a linked ticket that we can show on hover. What's your opinion? I think it is useful mostly for features we have not implemented, but they have no "supported version" to add. I am not sure you want to support that case.

I can add toolchain_rscpp.yaml, fill support and hints, and track them periodically. Unfortunately, I cannot test it: the repo has the data, the schema, and the validator, but no front end. So tell me the shape you want and I will match it.

[cdervis]

Hi @Smertig, thanks for the suggestion, and I'm glad cppstat is useful to you.

To answer your questions:

Do you want it at all? If a proprietary frontend does not fit the site, that is a fair answer.

My goal for cppstat was always to be a pragmatic tool, nothing philosophical. If something in the C++ world plays a reasonably large role, it deserves to be on there. CLion/ReSharper obviously plays a large role, so no, I don't mind putting proprietary tooling info on cppstat, even if it meant free advertisement in some form. It's no different to me than having MSVC on there, or cppreference putting EDG on their tables. I actually used CLion a lot and respect what your team accomplished with Nova performance-wise, and early modules support and now reflection. Good job on that, I can't imagine the complexity.

Where should it go? R++ is not a toolchain. [...]

I would put it in a separate "Frontends" column, right after toolchains. There would be a slightly thicker separator between toolchains and frontends, and there would be heading cell above each (see images).

There are a lot of library features. R++ implements no standard library [...]

Yes, I would make it so the site automatically shows a stylized n/a for stdlib features in frontend cells.

Our version numbers are of the form 2026.2 [...]

Not an issue at all, we have plenty of room left.

Most features have a linked ticket that we can show on hover [...]

You would simply declare the link to that feature's YouTrack ticket. If the support level is partial, cppstat can show a tooltip that automatically embeds that link. I think it sounds reasonable and doesn't hinder the design in any way.

Mockups

Here are some images of the design I'm experimenting with:

General Layout

Hovering

Stylized N/A for stdlib features

Toolchain Overview -> Tooling Overview

How we proceed

I'll prepare a special preview mode on cppstat which allows you to point it at an arbitrary GitHub repo and load the rscpp YAML. This means you can just fork cppstat, add all the necessary data at your pace, preview it live on cppstat, then we can squash merge it to main. Afterwards, I can assign a contributor role to you so you can directly contribute to this repo. I'll notify you here when it's ready, with an example YAML file so you know what cppstat expects, and how to fill it. Sounds good?

About EDG: I'm not certain about its future and whether it's worth it to maintain its support data. I don't know far behind/ahead EDG is compared to MSVC.

That all being said, I trust that you maintain the data reasonably well. Let me know if you have any more suggestions or feedback about the design.