.natvis workaround for cargo vendor

[kennykerr]

This is a quick workaround for what appears to be a cargo vendor issue that fails to include some files that are otherwise included by cargo package.

Fixes: #3606

[kennykerr]

I couldn't find a way to test cargo vendor as part of the build as it does not appear to support archiving path-based dependencies.

[tim-weis]

Since you are renaming the .natvis files could you consider using the crate names instead (i.e., windows-core.natvis, windows-result.natvis, windows-strings.natvis). That makes it easier to know which visualizers are present in a PDB, or loaded when debugging.

[ChrisDenton]

I couldn't find a way to test cargo vendor as part of the build as it does not appear to support archiving path-based dependencies.

Hm, cargo package might be another option for testing as it should work similarly. Remove (or move) the .git directory and then run, for example, cargo package -p windows-result. That should fail on the current master branch and succeed for this PR.

[kennykerr]

Thanks Chris, will debug this when I get a moment - in the meantime #3608 should unblock cargo vendor support.

[kennykerr]

Since you are renaming the .natvis files could you consider using the crate names instead (i.e., windows-core.natvis, windows-result.natvis, windows-strings.natvis). That makes it easier to know which visualizers are present in a PDB, or loaded when debugging.

Done in #3608

[tim-weis]

Since you are renaming the .natvis files could you consider using the crate names instead (i.e., windows-core.natvis, windows-result.natvis, windows-strings.natvis). That makes it easier to know which visualizers are present in a PDB, or loaded when debugging.

Done in #3608

Thanks for incorporating late feedback. Unfortunately, it didn't have the effect I expected: .natvis files dumped into the PDB continue to receive generic names (e.g., <bin crate>-0.nativs, <bin crate>-1.natvis, ...).

If there are no adverse effects, it would be nice to keep the changes regardless.

Apologies for not verifying my assumptions ahead of time.

[kennykerr]

Thanks for reporting that behavior - good to know.

[tim-weis]

FYI: The behavior is specific to the debugger_visualizer attribute. Natvis visualizers for core Rust libraries (like liballoc.natvis) are processed differently and retain their respective file names.