Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Natvis visualizations for core indexmap types #239

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ridwanabdillahi
Copy link

This change adds Natvis visualizations for some indexmap types to help improve the debugging experience on Windows.

Natvis is a framework that can be used to specify how types should be viewed under a supported debugger, such as the Windows debugger (WinDbg) and the Visual Studio debugger.

When debugging types such as IndexMap and/or IndexSet under a Windows debugger, the entries for these data structures are not always clear upon first glance. The internal data structure is shown and it's not presented in a user friendly way. The Rust compiler does have Natvis support for some types, but this is limited to some of the core libraries and not supported for external crates.

rust-lang/rfcs#3191 proposes adding support for embedding debugging visualizations such as Natvis in a Rust crate. This RFC has been approved, merged and implemented.

This PR adds:

Natvis visualizations for some of the core types such as IndexMap and IndexSet.
Tests for testing visualizers embedded in the indexmap crate.
Updates to the CI pipeline to ensure tests for visualizers are run so they do not break silently.
A new debugger_visualizer feature for the indexmap crate to enable the unstable debugger_visualizer Rust feature.

…g Natvis definitions do not become stale or break silently.
feature = "debugger_visualizer",
feature(debugger_visualizer),
debugger_visualizer(natvis_file = "../debug_metadata/indexmap.natvis")
)]
Copy link
Member

Choose a reason for hiding this comment

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

I'm personally very wary of using any unstable features in a stable crate, even behind an optional feature.

Copy link
Author

Choose a reason for hiding this comment

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

I understand, the goal is to push the debugger_visualizer feature to stabilization relatively soon by having it provide value to crates in the wild today as with any unstable feature.

As you said it is gated behind an optional feature but you as the crate maintainer would have to potentially take on an extra cost which I fully understand could be worrisome.

Copy link
Member

Choose a reason for hiding this comment

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

Well, I gave approval for CI to run, at least, so it can be a proof of concept for the feature.

Copy link
Author

Choose a reason for hiding this comment

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

Great! I see the CI was green and tests passed. Thanks for approving the CI job.

Copy link
Author

Choose a reason for hiding this comment

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

@cuviper Do you have any reservations about taking in this change now that the CI shows as green?

Copy link
Member

Choose a reason for hiding this comment

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

Passing CI is necessary, but doesn't change the maintenance aspect. If the unstable feature changes, as it is allowed, then we'll have to update again to fix our own CI. That's especially true if any users (on nightly) start depending on it (providing "value in the wild").

For ad hoc demonstrations in the meantime, you could use cargo's patch mechanisms to point at your git fork.

debug_metadata/indexmap.natvis Show resolved Hide resolved
tests/debugger_visualizer.rs Outdated Show resolved Hide resolved
@cuviper
Copy link
Member

cuviper commented Jun 27, 2023

The feature was stabilized in rust-lang/rust#108668, headed for Rust 1.71. Does this PR need updating for that? At the very least, we should not need the feature(debugger_visualizer) attribute anymore, but I don't know if there were any functional changes along the way.

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

Successfully merging this pull request may close these issues.

2 participants