VSCode: 1.10.2
cpptools: 0.10.4
MacOS: 10.12.3
I've noticed there's a lot of similar issues for this, but a lot of them are confounded. Sorry in advance if there's an existing issue I should follow instead.
When I try to right click on a function in stdlib.h and select "Go to Definition", I get a tooltip-like error that no definition was found. "Go To Definition" with a function in stdio.h has expected behavior.
However, if I "Go to Definition" on #include <stdlib.h>, I'm given a choice between /usr/include/c++/4.2.1/tr1/stdlib.h and /usr/include/stdlib.h. Maybe this contributes/causes the issue.
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
printf("contrived");
exit(0);
}
STR
exit().The definition is at /usr/include/c++/4.2.1/cstdlib, so opening that file should fix this, but we're still investigating why the file is sometimes not parsed automatically from the stdlib.h. There is no existing issue for this. It couldn't get a repro on 10.11.6, but I got repro on 10.12.3.
Okay, I got the repro on 10.11.6 too. The bug is caused by the fact that /usr/include/stdlib.h is being parsed instead of /usr/include/c++/4.2.1/tr1/stdlib.h . The file that isn't parsed has the #include to cstdlib, which contains the definition. Changing limitSymbolsToIncludedHeaders to false is a workaround. If we took the "tr1/" into account or parsed every matching file instead of the 1st match, that would fix this issue (or just set limitSymbolsToIncludedHeaders to false by default).
The bug is caused by the fact that /usr/include/stdlib.h is being parsed instead of /usr/include/c++/4.2.1/tr1/stdlib.h . The file that isn't parsed has the #include to cstdlib
For what it's worth, I'm working with C and not C++ code, so I would assume I want /usr/include/stdlib.h, and not /usr/include/c++/4.2.1/tr1/stdlib.h, but I'll defer to you.
That's good to know. Yeah, I thought you were using C++, so we have an additional problem then. The /usr/include/stdlib.h is being parsed, but it's not correctly picking up any of the symbols in the file. If I delete stuff in the file I can get symbols to be found, so there's something in the file that is causing our parser to fail. In the past this has been caused by macros. We'll investigate a fix...
It's a problem with the attributes at the end of the exit definition. You can work around this via opening cpp.hint in /.vscode/extension/ms-vscode.cpptools-\ Oh, and then you'll need to delete or rename your .browse.vc.db (or whatever you set your databaseFilename to).// Linux C lib
#define __THROW
#define __attribute_pure__
#define __nonnull(arg)
#define __wur
#define __attribute__(arg)
#define __attribute_warn_unused_result__
#define __attribute_malloc__
// Mac C lib
#define __dead2
#define __pure2
#define __result_use_check
#define __swift_unavailable(arg)
#define __scanflike(arg)
#define __printflike(arg)
#define __WATCHOS_PROHIBITED
#define __TVOS_PROHIBITED
#define __DARWIN_ALIAS(arg)
#define __DARWIN_ALIAS_C(arg)
#define __DARWIN_EXTSN(arg)
#define __OSX_AVAILABLE_STARTING(arg)
#define __OSX_AVAILABLE_BUT_DEPRECATED_MSG(arg)
fopen() was the only other I noticed (which I overlooked before, and leading to incorrect detail about only Intellisense parameter info for stdlib.h definitions), which adds __DARWIN_ALIAS_STARTING.
Ah, thanks, I missed that one. We'll fix that (either in the soon to be released update or the next one).
Fixed with 0.10.5 for stdlib/stdio. We have a backlog item for investigating other standard headers which have similar problems with custom attributes.