Add ReSharper C++ as a frontend?

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:

Do you want it at all? If a proprietary frontend does not fit the site, that is a fair answer.
Where should it go? R++ is not a toolchain. A new group such as "Frontends", or just one more column?
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?
Our version numbers are of the form 2026.2, which is a bit longer than just 12.3. Is that fine?
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.

@Smertig

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.

@cdervis

Hi @cdervis

I'm happy to hear you liked CLion :)

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.

That sounds great, thank you for your work! Layout looks very nice. If there's anything you don't want to share publicly, feel free to contact me via alexander.karaev at jetbrains.com.

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?

I did the fork, will wait for example of data shape and link to do preview, meanwhile I'll proceed with collection of data to fill in.

I have only one remaining small suggestion:

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.

I think the more common scenario for us is "feature is not supported at all, here's a tracking ticket for it (for upvoting or subscribing to track the progress)" - maybe we could show it as "-" with tooltip?

Alright, I've improved the YAML schema and tests, and the website is ready for preview. Please update your fork / pull main.

The frontend file must be at the root of the repo and be named frontend_rscpp.yaml.
Here's an example:

---
frontend:
  id: rscpp
  name: R++
  full_name: ReSharper C++
  vendor: JetBrains
  kind: frontend
  language: C++
  standard_library: false
  products:
    - CLion
    - Rider
    - ReSharper C++ for Visual Studio
  refs:
    - https://www.jetbrains.com/resharper-cpp/
issue_tracker:
  name: JetBrains YouTrack
  url_template: https://youtrack.jetbrains.com/issue/{id}
releases:
  - version: "2026.2"
    released: "July 2026"
    refs: [https://www.jetbrains.com/resharper-cpp/whatsnew/2026-2/]
  - version: "2026.1"
    released: "April 2026"
    refs: [https://www.jetbrains.com/resharper-cpp/whatsnew/2026-1/]

The frontend file only describes metadata about your frontend, just like with toolchains. The actual feature support data remains in the feature files. Please see the updated README for an example.

You can preview your fork by visiting https://cppstat.dev/?repo=Smertig/cppstat. If some cells are showing the purple "unverified" status, don't worry. I'll adjust the website after you're done with your data.

Feel free to provide feedback or report any issues here.

@cdervis

@cdervis great, thank you!

I started to fill in the data and found some issues so far:

language field in frontend schema seems either redundant (how is it used?) or should be extended to accept the list. R++ supports both C and C++.
Probably related to the p.1 - when I open https://cppstat.dev/?repo=Smertig/cppstat&type=lang (list, filtered only by language features), I correctly see purple "?" for the unverified rows in C++ groups, but "-" for rows in all C groups (the one with meaning "not applicable" rather than "not supported"). What's the expected state there?
Is it possible to allow setting frontend version support for library features? I believe some features are not pure-library, like P2996: Reflection for C++26 (<meta>) - it includes language support for std::meta::info magic type, and I'd like to explicitly mark this as supported by R++. Otherwise it looks like R++ supports everything in reflection, but not the "main" proposal.
It would be nice to allow named refs in frontend description, not just array of links. They are currently rendered as "Release link 1|Release link 2" when you have 2+ links, and human-readable names could help a lot there. Also spaces around "|" delimiter would be nice.
It would be nice to have customizable description for tooltip on hover on "R++" column in frontend_rscpp.yml. Currently it says "This column shows the version of ReSharper C++ that supports this feature". I don't think many people know what it actually means - that it's about IDE support (CLion/Rider and ReSharper C++ itself), and I'd add this short note there myself.
Tooltips for toolchains and frontend seems to be different in style - frontend has no version on hover, and no released date:

P.S. Mobile view looks a bit strange with purple "?":

@Smertig

@Smertig, thanks for the feedback!

I added language as general filter for potential future frontends, i.e. C++-only frontends. Removed it for now (won't have any effect).
The purple cells are meant for support that's not verified yet, may or may not be supported. The cppstat version I linked you simply showed this for R++ in general, which was wrong. If you want to indicate this support going forward, declare support: R++ ?. Question mark as the version indicates unknown support. Should be rare in your case, since you probably definitely know what's supported and what's not.
Yes, you can just declare the support for any feature. I added standard_library as a way to specify support for stdlib features by default. This means for R++, all stdlib features count as n/a unless you explicitly mark something as supported. Then it will show green support as usual.
I've expanded the schema now, see example below.
This is now covered by the description property.
Yes, that's just the unrefined mockup leftovers, and mobile was never really polished. Fixed both now.

Example

---
frontend:
  id: rscpp
  name: R++
  full_name: ReSharper C++
  vendor: JetBrains
  description: >-
    R++ is the C and C++ language engine powering code analysis and language
    support in CLion, Rider, and ReSharper C++ for Visual Studio.
  kind: frontend
  standard_library: false
  products: [CLion, Rider, ReSharper C++ for Visual Studio]
  refs:
    - title: Product page
      url: https://www.jetbrains.com/resharper-cpp/
issue_tracker:
  name: JetBrains YouTrack
  url_template: https://youtrack.jetbrains.com/issue/{id}
releases:
  - version: "2026.2"
    released: July 22, 2026
    refs:
      - title: Release notes
        url: https://www.jetbrains.com/resharper-cpp/whatsnew/

Edit: Please merge main again.

@cdervis

@cdervis thank you for your quick response and fixes 👍

Question mark as the version indicates unknown support. Should be rare in your case, since you probably definitely know what's supported and what's not.

I prepared PR with most of the data filled. Some gaps are still there, because it takes time to verify everything, but I'll add them later. I'm fine with fallback to "not supported" for now.

Everything else seems to be fixed and works perfectly!

Great, closing this then and PR also looks good. I'll invite you as a contributor, you don't need any further approvals to edit directly on cppstat then. Have a good day!

Navigation Menu

Repository navigation

Add ReSharper C++ as a frontend? #188