[Development] [Windows] State of the Qt6 natvis file

[Jörg Bornemann]

On 3/6/25 1:23 PM, Nicolas Arnaud-Cormos wrote:

>> That would exclude VS Code users on non-MSVC platforms.
>> But for starters one could focus on the VS thing.
> 
> This is already the case, as the current natvis is using some internals 
> of std::pairs only available on MSVC.

Maybe that can be fixed to use the common subset that VS Code 
understands too, but that would need investigation.

> Anyway, I scratched my itch (it's filling *my* use-case, mileage may vary):
> https://github.com/narnaud/natvis4qt
> 
> A small utility that installs or updates Qt5 and/or Qt6 natvis files in 
> known locations:
> - MSVC (supports 2019 and 2022), in the Visualizers directory
> - Qt dirs, in a natvis directory

That looks nice!

>  From doing that, I realized:
> 1) Contrary to my first thought, it doesn't make sense to integrate 
> natvis with the code
>    - if I had a new visualizer (like QDateTime), I want it for all Qt 
> versions, not the latest one
>    - it should be possible to handle multiple versions in the same 
> natvis file, using Optional or Priority (needs some proper testing though)

Makes sense. Let's move this forward and go with one repo with the 
monolithic natvis files then.

> 2) You need a tool that can handle all Qt versions, not the latest ones
>    - the tool is completely orthogonal to Qt versions
>    - it shouldn't follow Qt releases either, as you want the greatest 
> and latest natvis as soon as possible
>    - should handle auto-update (I don't want to think I need to update 
> the natvis file for my Qt 6.5 version I'm using on one project)

The VS extension and the VS Code extension need to handle this. Having a 
separate tool for people who don't want to or can't use these extension 
is of course nice.

> 3) You need to simplify contributions
>    - one source of truth (right now, the natvis file in the vscode 
> extension is behind the one in the Qt vsaddin for example)

agreed

>    - change license (MIT is the license I've seen in all the external Qt 
> natvis code I found)

I personally don't mind, but cannot make the call.
BTW, BSD is what we use for "build stuff". Natvis files seem to loosely 
fall into this category.

>    - remove namespace (In almost 25 years of Qt, I yet to see someone 
> using a namespaced Qt... worst case we could introduce them back by code)

Yes! The ##NAMESPACE## placeholder is horrible.

The namespace replacement that the VS extension does can be achieved 
differently:
s/<Type Name="Q/<Type Name="MyNamespace::Q/g

>    - generally speaking, reduce the barrier of entry (no need to dig 
> into a big repository to find the natvis file to change, just to realize 
> you need to change it in 2 different locations...)

agreed

> 4) Autotest
>    - I really like the idea of Squish testing the natvis inside Visual 
> Studio, that's probably the only way to go
>    - Ideally an overview of what is working in which Qt versions, but 
> that's a stretched goal

Let's ignore that for the time being.

> natvis4qt fills 1), 2) and 3). 4) is outside my reach. The integration 
> from CMake could also be interesting, but I'm not sure what would be the 
> best way to do that...

Not sure how that's going to work if the natvis files are not part of Qt.

Let's focus on the next steps. I propose to do the following on our side:

1. Consolidate the two copies of natvis files in the qtvstools repo. Why 
do they exist?
2. Remove the namespace from the files and adjust the namespace 
replacement code.
3. Move the updated natvis files to a central location. We already have 
https://codereview.qt-project.org/admin/repos/qt-labs/vs-debugtools,general 
Why not use that.
4. Make the VS and VS Code extension use the natvis files from there. 
Either via a git submodule or an update script or such.


How does this sound?


Cheers,

Joerg

-- 
Jörg Bornemann | The Qt Company