- VSCode Version: Code 1.16.1 (27492b6bf3acb0775d82d2f87b25a93490673c6d, 2017-09-14T16:38:23.027Z)
- OS Version: Windows_NT x64 10.0.15063
- Extensions:
| Extension |
Author (truncated) |
Version |
| cpptools |
ms- |
0.13.0 |
Steps to Reproduce:
- Open project attached
test.zip
- Open include/type1/type.h
- Use the C_Cpp.SwitchHeaderSource hotkey (default: ALT + o)
Expected: Opens up src/type1/type.cpp
Actual: Opens up src/type0/type.cpp
When using the standard include/ + src/ and subfolders structure to allow for files to have the same name (eg. debug.h might exist in multiple places and is disambiguated by using the full relative path from the include/folder), the C_Cpp.SwitchHeaderSource hotkey seems to slip up. It looks like if going from header to source file it just looks for the first file that has the same name and a different extension.
Looking through the c_cpp_properties.json file, it looks like there might not be enough information for this to work correctly. A 'sourcePath' field which allows for correct traversing of the include tree might be needed. Maybe on an ALT+o press, you might need to traverse up the folder structure until you hit the first includePath and use that relative path to then traverse down the sourcePath in order to find the correct cpp file.
PS. The use case is something like this:
Let's say there are implementations for I2C and SPI busses and normally the include in application code might look like this:
#include <companyname/bus/spi/bus.h>
#include <companyname/bus/i2c/bus.h>
I then ctrl+click the spi bus.h. Then I subsequently press alt+o to get to the SPI bus's cpp file. Instead of going to the SPI bus's cpp file, I might instead end up in the I2C bus's cpp file and modify the wrong file (which has happened).
Steps to Reproduce:
test.zip
Expected: Opens up src/type1/type.cpp
Actual: Opens up src/type0/type.cpp
When using the standard include/ + src/ and subfolders structure to allow for files to have the same name (eg. debug.h might exist in multiple places and is disambiguated by using the full relative path from the include/folder), the C_Cpp.SwitchHeaderSource hotkey seems to slip up. It looks like if going from header to source file it just looks for the first file that has the same name and a different extension.
Looking through the c_cpp_properties.json file, it looks like there might not be enough information for this to work correctly. A 'sourcePath' field which allows for correct traversing of the include tree might be needed. Maybe on an ALT+o press, you might need to traverse up the folder structure until you hit the first includePath and use that relative path to then traverse down the sourcePath in order to find the correct cpp file.
PS. The use case is something like this:
Let's say there are implementations for I2C and SPI busses and normally the include in application code might look like this:
I then ctrl+click the spi bus.h. Then I subsequently press alt+o to get to the SPI bus's cpp file. Instead of going to the SPI bus's cpp file, I might instead end up in the I2C bus's cpp file and modify the wrong file (which has happened).