For some reason, the project I am working on names some of it's Cpp header files as *.x
It looks like these files are not being indexed by Clangd and I end up with the following error whenever I try to use references, definitions on objects declared here.
[coc.nvim]: Error on notification "jumpDefinition": definition provider not found for current buffer, your language server doesn't support it.
clangd + coc, works for all other extension types like *.cpp, *.c, *.h, *.hpp. Is there any configuration file where I can add the *.x files as well
Related
I am writing a VSCode C++ extension. I would add an include instruction to the current file (which uses the type).
It is like an import instruction in JS.
How can I get the file path of the file where the type is defined?
Is there a way to get the file of goToTypeDefinition or goToDefinition?
you can get the path of the current file with
vscode.window.activeTextEditor.document.uri
When using VS Code in Linux for C++, I found that there are two files I need to configure: tasks.json and c_cpp_properties.json.
For tasks.json, there is:
"args": [ "-I", "$PATH",]
and for c_cpp_properties.json, there is:
"configurations": ["includePath": ["$PATH1"], ...]
So what's the difference between them? If I need to include a header file, which one should I use?
The tasks.json is the one you need to compile/build your C++ application. If you are adding a new header file, you'll definitely need to specify the path to that header file in args, so that it gets passed to your compiler.
From: https://code.visualstudio.com/docs/cpp/config-msvc#_create-a-build-task
The args array specifies the command-line arguments that will be
passed to the compiler that was specified in the previous step. They
must appear in the order expected by the compiler.
You definitely need to set this properly if you are compiling/building using VS Code.
The c_cpp_properties.json is mainly used to support the intellisense and auto-completion features of the C++ extension. The includePath tells the extension where to find the header files, so that you can do things like "Go to definition" or other code navigation operations.
From: https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference#_configuration-properties
includePath An include path is a folder that contains header files
(such as #include "myHeaderFile.h") that are included in a source
file. Specify a list of paths for the IntelliSense engine to use while
searching for included header files. If a path ends with /** the
IntelliSense engine will do a recursive search for header files
starting from that directory. If on Windows with Visual Studio
installed, or if a compiler is specified in the compilerPath setting,
it is not necessary to list the system include paths in this list.
You can also modify c_cpp_properties.json by accessing the Intellisense Configurations UI, by accessing the command palette > C/C++: Edit Configurations (UI).
You can survive without configuring c_cpp_properties.json properly. It's not required to compile/build C++ code. But it can be quite helpful when you're writing your code.
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL . However, during compilation it cannot found some header files, namely
pg_config_ext.h and pg_config_os.h.
While looking at the directory structure of PostgreSQL, I find that it does not have these header files. How to fix this issue?
These header files are generated from the respective .in files when configure is run.
This will allow conditional compilation depending on the operating system and its configuration.
To compile PostgreSQL, you need what is called a configured source tree in PostgreSQL jargon.
Also note that the build process is somewhat different on Windows, see the documentation for details.
I have some C++ code that I need to compile using Adacore GNAT Programming Studio.
One file (SomeHeader.h) is in a Common directory (../../Common/) relative to my GPR file.
Our convention for C++ include directives is to use
#include "Common/SomeHeader.h"
No matter what I do, I cannot get GprBuild to find "Common/SomeHeader.h"
I followed the instructions here at AdaGem 108 with modifications for C++
for Include_Switches ("c++") use ("-I ../../");
and
for Include_Path ("c++") use "../..";
None of this seems to work for me during gprbuild and frustratingly I can't seem to get at the backend command that gprbuild is using even after turning the build verbosity up.
I see some temp files in the build messages but they get deleted before I can access them.
I am using Adacore GPS 17.1 on Windows 10 i686-pc-mingw32, GNAT Pro 17.1.
Does anyone know how to get include search paths working in Adacore's Gprbuild?
If you want to use relative paths, and you are dead set on using the -I flag, be aware that the current directory at the time you compile your c++ code it is set to the obj directory configured for grp.
So if the directory you want to include is located at C:\Foo\Bar\src\include\ and your grp obj directory is at C:\Foo\Bar\env\gpr\obj then your relative path will need to use -I..\..\..\src\include
I haven't tried to use gprbuild for compiling C++ source text yet, but I suppose it works more or less like with Ada, where you add the relevant directories to the Source_Dirs attribute:
project Cookie is
for Languages use ("C++");
for Source_Dirs use (".",
"../..");
[...]
end Cookie;
I am using Eclipse Juno CDT for a class I am taking, but it is telling me it can't resolve types found in include files, and these aren't headers I wrote.
The program I wrote compiles and runs exactly as it should if I run it through g++ via the command line. The problem is that I can't debug in Eclipse because it doesn't recognize even basic types like string. Also, no code completion. It finds the include files just fine, I can open those and look at the contents, but it still won't resolve types.
I've seen lots of suggestions for people with similar problems, but those all turned out to be not finding the include files, which isn't my problem. Any suggestions?
Maybe the types are in a namespace and you're not qualifying them (and not using a using declaration).
You likely have included the proper directory for the headers themselves. On my system it is: /usr/include/c++/4.4.6/
However, you probably don't have the directory containing the definition of the macro _GLIBCXX_BEGIN_NAMESPACE. Without this macro definition eclipse does not know that the stl types are in the std namespace. On my system this macro definition is squirreled away beneath the main c++ dir. Try adding the following paths to your include list:
/usr/include/c++/4.4.6/x86_64-redhat-linux
/usr/include/c++/4.4.6/x86_64-redhat-linux/bits
If you're not on redhat look for something similar. You can go to /usr/include and run the following grep to look for the headers with the necessary macro definition:
grep -R -P "define\\s*_GLIBCXX_BEGIN_NAMESPACE\(" .