Include directives with path containing Linux symbolic links not followed for symbols.

[ijd02]

Type: LanguageService
When an include directive specifies a header file and includes some path information where one directory is a symbolic link then the file can't be found using "Go to Definition".

For example when attempting to right click and "Go to Definition" for the include directive:
#include <asm/arch/sys_proto.h>

The result is:
"No definition found for 'sys_proto'"

Depending where in the include directive you click you may see different fail messages like "No definition found for 'asm'"

There are no squiggly lines underneath the include directive it appears on some level the file can be found. As expected if I delete the file a red squiggle will appear to indicate the file is missing.

Additionally when I use "Go to Symbol in Workspace..." to find a symbol declared in 'sys_proto.h, like set_wdog_reset() then the symbol is successfully found.

In the above case the "arch" directory is actually a symbolic link pointing to a directory called "arch-mx6".

Right click and "Go to Definition" for all other include directives in c file work correctly.

System Setup
OS:
CentOS Linux release 7.4.1708 (Core) x86_64

VS Code Version:
Version: 1.29.0
Commit: 5f24c93878bd4bc645a4a17c620e2487b11005f9
Date: 2018-11-12T07:42:27.562Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64

C/C++ Extension Version:
0.20.1

Other extensions:
None

To Reproduce

1. Get Uboot source code (maybe from freescale/NXP)
2. Open VSC and create a workspace pointing to the uboot source code directory
3. Configure C++ extension worskpace settings such that C_Cpp.default.browse.path points to directory with uboot code and C_Cpp.default.includePath points to uboot "include" directory and "arch/arm/include" directory.
4. Open /drivers/mmc/fsl_esdhc.c
5. Right click on #include <asm/arch/sys_proto.h>
6. See error message indicating sys_proto can't be found

Code Snippet
/*

• Copyright 2007, 2010-2011 Freescale Semiconductor, Inc
• Andy Fleming
• Copyright 2017 NXP
• Based vaguely on the pxa mmc code:
• (C) Copyright 2003
• Kyle Harris, Nexus Technologies, Inc. kharris@nexus-tech.net
• SPDX-License-Identifier: GPL-2.0+
  */

#include <config.h>
#include <common.h>
#include <command.h>
#include <errno.h>
#include <hwconfig.h>
#include <mmc.h>
#include <part.h>
#include <malloc.h>
#include <fsl_esdhc.h>
#include <fdt_support.h>
#include <asm/io.h>
#include <dm.h>
#include <asm-generic/gpio.h>
#include <power/regulator.h>
#include <asm/arch/sys_proto.h>

Expected behaviour
When right clicking on an include directive and selecting "go to definition" the IDE would open the file specified in the include directive.

Additional context
My work space settings file is this:
{
"folders": [
{
"path": "/home/ian/Linux/Output/ramdisk/build/uboot-rel_imx_4.9.x_1.0.0_ga.rel_imx_4.9.x.18ian"
}
],
"settings": {
"files.exclude": {
"**/.o": true
},
"C_Cpp.default.browse.path":[
"/home/ian/Linux/Output/ramdisk/build/uboot-rel_imx_4.9.x_1.0.0_ga.rel_imx_4.9.x.18ian"
],
"C_Cpp.default.includePath": [
"/home/ian/Linux/Output/ramdisk/build/uboot-rel_imx_4.9.x_1.0.0_ga.rel_imx_4.9.x.18ian/arch/arm/include/",
"/home/ian/Linux/Output/ramdisk/build/uboot-rel_imx_4.9.x_1.0.0_ga.rel_imx_4.9.x.18ian/include"
],
"C_Cpp.default.intelliSenseMode": "gcc-x64",
"files.associations": {
"dm.h": "c",
"fdt_support.h": "c",
"malloc.h": "c",
"part.h": "c",
"gpio.h": "c",
"regulator.h": "c",
"wdt.h": "c",
"io.h": "c",
"common.h": "c",
"config.h": "c",
"command.h": "c",
"linker_lists.h": "c",
"compiler.h": "c"
}
}
}

[sean-mcmanus]

We have a task to reimplement Go to Definition on #include lines at #2564 . Fixing that would potentially address this issue as well.

[TDHolmes]

I believe this is still an issue. Any update on this?

[rbeesley]

Trying to build a cross-compilation system, I have header files I'm trying to "normalize" to lower cased filenames using symbolic links. I'm seeing that those header files which are referenced directly load fine and those which are symbolic links to the source file fail to load properly. x86_64-w64-mingw32-gcc is able to build everything without errors, so this seems to be a problem with VSCode IntelliSense. I'm including this testimony because it demonstrates that the files are being parsed in the given include directory, and that symbolic links are not, yet this is a valid way to create project as other tools, specifically the gcc compiler, are able to compile and produce the expected object files.