Clang Complete for Vim - vim

I copied clang_complete.vim to plugin, but when I typed . after some variable, it says:
pattern not found
I searched this issue, and somebody said I should configure g:clang_complete_auto: and g:clang_complete_copen:. How can I do this?

I had the same problem and resolved it by adding the following to my .vimrc
let g:clang_user_options='|| exit 0'

Try opening a sample file
vim /tmp/sample.cpp
and enter some cpp code
#include <iostream>
int main() {
std:: // <-- this should complete
}
Note that you actually need to include the headers, since completion is done with the compiler. If this works, but your project still keeps saying "Pattern not found" then clang++ is probably not able to compile your project. Do you use any -I switches when you compile your code? Add them to a file named .clang_complete in your project directory.
For me this works fine with my .vim/plugin folder containing only the clang_complete.vim file that is available for download:
$ find .vim
.vim
.vim/plugin
.vim/plugin/clang_complete.vim
... but in this issue report https://github.com/Rip-Rip/clang_complete/issues/39 it is suggested that you might need more than that file (additional files are in the git repo).

The following got things working for me on Cygwin using clang version 3.0 (tags/RELEASE_30/final), as well as on Windows using the Clang build instructions and a version checked out from trunk (usually stable, as I've read) yesterday (clang version 3.1 (trunk 154056)) and built with Visual Studio 2010:
" clang_complete
let g:clang_complete_auto = 0
let g:clang_complete_copen = 1
" :h clang_complete-auto_user_options
if has('win32unix') " Cygwin
" Using libclang requires a Vim built with +python
let g:clang_use_library = 1
" Mit der Option "gcc" kriege ich Fehler.
" Remove "gcc" option as it causes errors.
let g:clang_auto_user_options='path, .clang_complete'
elseif has('win32') " Windows
let g:clang_auto_user_options='path, .clang_complete'
let g:clang_use_library = 1
let g:clang_library_path='D:\Sourcen\LLVM\build\bin\Debug'
endif
Note that the Windows version may have sporadic assertion failures but works fine, although not exactly like the Cygwin version. Guess it's to do with using MSVC versus GCC header files.
The Cygwin version has an initial error: release unlocked lock, but it works regardless.

Did you try to compile the code outside Vim, by explicitly invoking Clang on the command-line?
I had the same problem with my code, but it turns out Clang was not able to compile my code due to usage of the MPI libraries (mpich2). Maybe a similar problem is causing Clang to fail in your case? In my case, if I remove the MPI-dependencies, everything works fine, for example in something like:
#include <iostream>
#include <string>
int main() {
std::string myString("test string");
std::cout << myString.size() << std::endl; // After typing the dot, I get a list of std::string methods
}
By-the-way, I still miss clang_complete in my MPI code. Did anyone find a solution for this?

To configure Vim, you must find or create your .vimrc file:
$ vim ~/.vimrc
Then enter:
let g:clang_complete_copen = 1

Related

Visual Studio Code-Cannot open source file "iostream"

I just want to try c++ coding with Visual Studio code. I have installed vscode 1.18.1 to my laptop (Win10-64).
I got errors by typing following code:
#include <iostream>
using namespace std;
int main()
{
std::cout << "Hello world!" <<endl;
return 0;
}
Should happen no Error. C:\Users\Harri\OneDrive\Tiedostot\Demo2.vscode\c_cpp_properties.json -content:
"path": [
"/usr/include",
"/usr/local/include",
"${workspaceRoot}"
],
Problems/Errors for row 1:
" #include errors detected. Please update your includePath. IntelliSense features for this translation unit (C:\Users\Harri\OneDrive\Tiedostot\Demo2\Calc.cpp) will be provided by the Tag Parser. "
" cannot open source file "iostream" "
The main problem is cygwin paths
You have cygwin paths like /usr/include in your c_cpp_properties.json file. That is a problem because VSCode does not understand cygwin paths. At a cygwin shell you can run:
$ cygpath -w /usr/include
D:\cygwin64\usr\include
to get the equivalent Windows path. Put that into c_cpp_properties.json instead. Remember that you have to double the backslashes when you copy this into a JSON string.
Other suggestions
This SO answer describes how to set up VSCode with cygwin gcc. I haven't tried those instructions but they look reasonable.
Beyond that, I highly recommend going through the Get Started with C++ tutorial on the VSCode site. It might directly answer your question, but even if it doesn't, having a working setup to compare to is valuable.
Also, look at the C/C++ diagnostics: View → Command Palette... → C/C++: Log Diagnostics. This will show things like which compiler VSCode is trying to emulate and what it thinks the #include paths are.
Finally, to get lots of useful information directly from your compiler to compare with what VSCode thinks, if you are using gcc, run at a cygwin or bash prompt:
$ touch empty.c
$ gcc -v -E -dD empty.c > compiler-info.txt
That will write to compiler-info.txt all the predefined macros, #include search paths, default target, etc.
For some reason iosteam is a typo
Try using instead. It worked for me.
Working Code Screenshot

Building Skia on Windows 32 bit

I'm building Skia on Windows following this link.
For Windows x64 the build was quite smooth. But not for 32 bit.
1) I tried specifying target_cpu = "x86" instead of target_cpu = "x64", gn gen works fine but ninja throws errors complaining that the paths to visual studio contain spaces. It has all sorts of errors similar to the following:
"C:\Programs " is not a valid path.
2) I tried generating sln files and building from within IDE (which is an alternative as mentioned in the link). However, I can't even get the x64 version to compile this way (a lot of non-zero exit codes from ninja, no further messages observed).
3) I tried using the toolchain that the website claims to be "the only way to support 32 bit builds". The toolchain is to be downloaded using the following command (to be executed in skia dir):
python infra/bots/assets/win_toolchain/download.py -t C:/toolchain
I managed to work around loads of intricacies (gutil conflicts, .py extension omissions, path variables, to google cloud service) and I'm now stuck at this:
Logged in as xxxxxxxxxxxxxxxx
AccessDeniedException: 403 Caller does not have storage.objects.list access to bucket skia-buildbots.
I'm not restricted to the way it is built so long as it generates the "libs" for me. But with a large project having so many external dependencies I don't think it's easy to brew my own way.
One solution I've found:
Open the out\Release\toolchain.ninja text file (or the toolchain.ninja specific to your configuration)
Remove the following string (you can use a "Replace Text" with an empty string in your text editor):
C:/Program Files (x86)/Microsoft Visual Studio 14.0/win_sdk/bin/SetEnv.cmd /x86 && C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64_x86/
from everywhere (in case that you've used the x86, for x64 the string might be different)
And use ninja -C out/Release dm as usual
In this way we are using a toolchain where cl.exe, ml.exe link.exe commands are called directly (accesible from the PATH environment)
An other solution base on #dacap's. But I edit the gn configure instead.
Change file gn/toolchain/BUILD.gn
...
if (msvc == 2015) {
bin = "$win_vc/bin/amd64"
} else {
bin = "$win_vc/Tools/MSVC/$win_toolchain_version/bin/HostX64/$target_cpu"
}
env_setup = ""
if (target_cpu == "x86") {
# Toolchain asset includes a script that configures for x86 building.
# We don't support x86 builds with local MSVC installations.
env_setup = "cmd /c $win_sdk/bin/SetEnv.cmd /x86 && "
}
...
To
...
if (msvc == 2015) {
if (target_cpu == "x86") {
bin = "$win_vc/bin"
} else {
bin = "$win_vc/bin/amd64"
}
} else {
bin = "$win_vc/Tools/MSVC/$win_toolchain_version/bin/HostX64/$target_cpu"
}
env_setup = ""
#if (target_cpu == "x86") {
# # Toolchain asset includes a script that configures for x86 building.
# # We don't support x86 builds with local MSVC installations.
# env_setup = "cmd /c $win_sdk/bin/SetEnv.cmd /x86 && "
#}
.....
It seems that (as of skia m67) #WinCloud's fix is partially merged to upstream (still has to remove env_setup part though).
However, as noted in comments - it will crash during OpenGL initialization.
I've fixed all that (at least to the point where demo apps are runnable), as a little extra - fixed .lib compatibility with Visual Studio's Debug configurations.
Included are .bat files that build "no system libs" configuration with Clang (as the readme explicitly states that VC++ builds may have performance issues). To use those just download latest LLVM from https://releases.llvm.org/download.html and install it into default location (tested with 6.0.0).
If you need DLL runtime linking you'll have to edit gn/BUILD.gn file - add /MD flag by default and change /MTd to /MDd for debug.
Here's patch based on chrome/m67 branch:
https://gist.github.com/Alexx999/39eae9182eecaa3dc06e73fdb3a1e7d9

Syntastic Error with Fortran Module

I use both intel and gnu fortran compilers. Syntastic gives the following errors when I compile my module, with these settings:
syntastic_fortran_compiler set to 'ifort' & using ifort -c my_mod.f90, then it displays an error on the USE my_mod line.
syntastic_fortran_compiler set to 'gfortran' & using gfortran -c my_mod.f90, then it displays an error on the CALL subroutine line.
To change the value of syntastic_fortran_compiler, I edit the file: syntastic-checkers.txt by accessing it through :help syntastic-checkers-fortran in vim.
There is no problem with the code running though; everything is fine. The module does what it is supposed to. I like the loc_list when it displays errors, but it is irritating when it comes up with a non-removable, non-error. For now, I have set let g:syntastic_auto_loc_list = 0.
This is produced on a machine with gcc version 4.8.4. An interesting thing is that when I do this on a machine with gcc version 5.*, the gfortran error disappears. Also, I use ifort version 16.0.3 .
EDIT1: I see the errors when I open the main program file with vim after I compile as above.
EDIT2: As lcd047 mentions in the comments, I am supposed to add let g:syntastic_fortran_compiler ="ifort" to my .vimrc. Doing so resolves error(1), and now both cases produce error(2).
EDIT3:
The funniest thing happened. After I performed EDIT2, I indented the code inside the SUBROUTINE contained in my MODULE, because the cursor kept jumping one indent every time I pressed enter, and it was getting irritating (up until now all code in the module was without indentation).
Then, when I opened my main file this time, syntastic actually tells me what is wrong as an error message (till now it only said error). Message: The type of the actual argument differs from the type of the dummy argument. It underlined all the REALs amongst the args (I have REAL and INTEGER args).
So then I open my_mod.f90 to check; everything seems okay. And this time when I open main.f90, there isn't an error anymore. What I wrote above is all I did. I have no idea how the error disappeared.
EDIT4: The above effect is reproducible. When g:syntastic_fortran_compiler = "ifort", if I compile once with gfortran, and open the file, syntastic says that it does not recognize the module. That is okay. Now, if I compile again with ifort, syntastic gives that error message of differing types again. Closing and opening the file again removes the error.

Code Blocks output doesn't execute linux

I am pretty new to linux and i wanted to try to make a small opengl
program just as a test. I'm using glfw and i made a very easy test:
#include <iostream>
#include <GL/glew.h>
#include <GLFW/glfw3.h>
using namespace std;
int main()
{
if (!glfwInit())
{
return -1;
}
GLFWwindow *window = glfwCreateWindow(800, 600, "Het werkt", NULL, NULL);
if (!window)
{
glfwTerminate();
}
glfwMakeContextCurrent(window);
while (!glfwWindowShouldClose(window))
{
glfwPollEvents();
glfwSwapBuffers(window);
}
}
Now if i try to run this in Code::Blocks itself, it runs fine, debug, release, it doesn't matter, it works. But when i try to execute it outside Code::Blocks, it goes wrong. If i double click the executable nothing happens, and if i ./ExecutableName in the terminal it gives me this error:
error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
All of the libs are in the same directory as the executable, so i don't get why it gives this error.
By the way i'm working on Linux Mint.
Thanks in advance for your help!
You should place those libraries in your $PATH. Issue a echo $PATH command and see if you can find the libraries in there (within those paths) - if not, you will have to put them in there someway. I'm not sure if you can just copy-paste the libraries in there, so probably you may want to search for them using your linux distribution's package management system. As you are using Linux Mint, maybe you could try searching with sudo aptitude search glfw and then try installing the corresponding packages.

NDK APP_CFLAGS can't handle <> characters?

I am including a procedurally generated file into code used by several libraries, using something like
#include MY_CONFIG_FILE_H
Then I am attempting to set this value in my Application.mk using the following directive
APP_CFLAGS += -DMY_CONFIG_FILE_H=<Config/MyFile.h>
however, this results in ndk-build not finding the path. It fails right away on the first file it tries to compile
"Compile++ thumb : MyLibraryName <= MyFirstFile.cpp
The system cannot find the path specified.
make: *** [obj/local/armeabi-v7a/objs/MyLibraryName/MyFirstFile.o] Error 1
Indeed, the file is not there, but it did manage to create the file path. There must be some strange/inconsistent string manipulation going on.
Any ideas? Work arounds? Is this a known issue in ndk-build.cmd? For the record I'm on Windows x64 and NDK R9.
Also notice that if I only include > and no <, I get a different error
The filename, directory name, or volume label syntax is incorrect.
Changing the line to
APP_CFLAGS += -DMY_CONFIG_FILE_H="<Config/MyFile.h>"
worked. Hope this helps anyone else!

Resources