Skip to content

godot-cpp.natvis debug visualizers#1977

Open
van800 wants to merge 5 commits intogodotengine:masterfrom
van800:shakhov/natvis
Open

godot-cpp.natvis debug visualizers#1977
van800 wants to merge 5 commits intogodotengine:masterfrom
van800:shakhov/natvis

Conversation

@van800
Copy link
Copy Markdown

@van800 van800 commented Apr 28, 2026

The original godot.natvis exists in the
https://github.com/godotengine/godot/blob/master/platform/windows/godot.natvis
and only supported godot::String and the godot::StringName was added recently in godotengine/godot#116955

Discussed in https://chat.godotengine.org/channel/gdextension?msg=mCgwe4cCkP3b43TjY
We realized there is no point in keeping godot-cpp type in the godot.natvis in the godotengine repo. All the types in godot-cpp are not the same - godot-cpp wraps the original godotengine types.

Support for godot::Array, godot::Dictionary and godot::Variant was added in this PR.

I have only tested the PR with JetBrians Rider. Just having the file, where it is located now is enough to automatically be used for debugging.

Related JetBrains tickets: https://youtrack.jetbrains.com/issue/RIDER-131718/Windows-Debug-GdExtension-from-Rider-usability, https://youtrack.jetbrains.com/issue/CPP-35297/Natvis-support-on-macOS-Linux-with-lldb, https://github.com/JetBrains/godot-support/wiki/Developing-godot%E2%80%90cpp.natvis

image

@van800 van800 requested a review from a team as a code owner April 28, 2026 19:20
@van800
Copy link
Copy Markdown
Author

van800 commented Apr 28, 2026

Resolves godotengine/godot-proposals#10605

Copy link
Copy Markdown
Collaborator

@dsnopek dsnopek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

I haven't tested, because I'm not a Rider or MSVC user. However, in general, I'm in support of including a .natvis file in godot-cpp.

Overall, the comments here seem quite verbose and not super useful. If they can be trimmed down to the essentials, that would be nice.

This doesn't include all the same types that are in godot.natvis - is the idea that folks will use both godot.natvis and godot-cpp.natvis together, and those types are covered by the godot.natvis?

Comment thread natvis/godot-cpp.natvis Outdated
Comment thread natvis/godot-cpp.natvis Outdated
Comment thread natvis/godot-cpp.natvis Outdated
@dsnopek dsnopek added the enhancement This is an enhancement on the current functionality label Apr 28, 2026
@dsnopek dsnopek added this to the 10.x milestone Apr 28, 2026
@van800
Copy link
Copy Markdown
Author

van800 commented Apr 29, 2026

Thank you for the comments!

This doesn't include all the same types that are in godot.natvis - is the idea that folks will use both godot.natvis and godot-cpp.natvis together, and those types are covered by the godot.natvis?

To my understanding it is not possible to directly use godotengine types in a gdextension, only their wrapped godot:: forms. Is that correct?
If it is correct, then there is no gain in having the godot.natvis for debugging a gdextension.

@dsnopek
Copy link
Copy Markdown
Collaborator

dsnopek commented Apr 29, 2026

To my understanding it is not possible to directly use godotengine types in a gdextension, only their wrapped godot:: forms. Is that correct?

Yes, but godot-cpp has it's own version of many of the types, including the containers like List, HashSet, etc and variant types like Basis, Transform3D, etc

All of these types are represented in godot.natvis, but the godot-cpp.natvis in this PR only has:

  • String
  • StringName
  • Array
  • Dictionary
  • Variant

What aren't all the types that are in godot.natvis included in godot-cpp.natvis too?

@van800
Copy link
Copy Markdown
Author

van800 commented Apr 30, 2026

You are right that we'd need to add those ~20 remaining types.
Adding those 3 types (godot::Array, godot::Dictionary, godot::Variant) took the whole working day.
Is it a blocker to add all the types at once?
Is it a blocker to ensure VS works with it?

I would be happy to continue working on adding more types, but I can't dedicate the whole week in a row to it.
Can we agree to split the work into several PRs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement This is an enhancement on the current functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants