Using default .ycm_extra_conf.py, the standard c++11 headers are not found. #303

Closed
cebrusfs opened this Issue May 8, 2013 · 62 comments

Projects

None yet
@cebrusfs
cebrusfs commented May 8, 2013

I set g:ycm_global_ycm_extra_conf in my vimrc.

let g:ycm_global_ycm_extra_conf = '~/.vim/bundle/YouCompleteMe/cpp/ycm/.ycm_extra_conf.py'

After including a c++11 header unordered_map, I got 'unordered_map' file not found reported by Syntastic plugin.

After adding

'-I',                                                                              
'/usr/include/c++/4.2.1/tr1/'

in flags in .ycm_extra_conf, now my problem is solved.

In default .ycm_extra_conf, the environment didn't include any c++11 headers, but the argument -std=c++11 still in flags?

I think it's strange. Something should be wrong.

I use the mac os 10.7.5 (Lion) and the following is report by :YcmDebugInfo command, hope it helps.

-- Flags for /Users/cebrusfs/test.cpp loaded from /Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/.ycm_extra_conf.py:
-- ['-Wall', '-Wextra', '-Werror', '-Wc++98-compat', '-Wno-long-long', '-Wno-variadic-macros', '-fex
ceptions', '-DNDEBUG', '-DUSE_CLANG_COMPLETER', '-std=c++11', '-x', 'c++', '-isystem', '/Users/cebru
sfs/.vim/bundle/YouCompleteMe/cpp/ycm/../BoostParts', '-isystem', '/System/Library/Frameworks/Python
.framework/Headers', '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/../llvm/include'
, '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/../llvm/tools/clang/include', '-I',
 '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/.', '-I', '/Users/cebrusfs/.vim/bundle/YouComple
teMe/cpp/ycm/./ClangCompleter', '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/./tes
ts/gmock/gtest', '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/./tests/gmock/gtest/
include', '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/./tests/gmock', '-isystem',
 '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/./tests/gmock/include', '-I', '/Users/cebrusfs/.
vim/bundle/YouCompleteMe/autoload/../python/clang_includes']
-- Has Clang support compiled in: True
-- clang version 3.2 (tags/RELEASE_32/final)
@pedrovanzella

This didn't work for me.
It keeps saying that random doesn't exist.

Also, I get the same thing as #192.

@oblitum
Collaborator
oblitum commented May 8, 2013

I've gone through this too and assumed that the current behavior won't try check clang default include directories from compiler flags as -std=libc++ and -std=c++11 for example. They can be verified with echo | clang -std=c++11 -stdlib=libc++ -v -E -x c++ -

@pedrovanzella

I found out that YCM keeps adding '-I', '/Users/pedrovanzella /dotfiles/vim/bundle/YouCompleteMe/autoload/../python/clang_includes' to the flags, and this makes compilation fail.

This works fine:

clang++ hello.cpp -Wall -Wextra -Werror -Wno-long-long -Wno-variadic-macros -fexceptions -DNDEBUG -DUSE_CLANG_COMPLETER -std=c++11 -stdlib=libc++ -x c++ -c

This fails:

clang++ hello.cpp -Wall -Wextra -Werror -Wno-long-long -Wno-variadic-macros -fexceptions -DNDEBUG -DUSE_CLANG_COMPLETER -std=c++11 -stdlib=libc++ -x c++ -c -I /Users/pedrovanzella/dotfiles/vim/bundle/YouCompleteMe/autoload/../python/clang_includes

I stripped .ycm_extra_conf.py bare, but YCM keeps adding this to the flags.

@pedrovanzella

I found this: https://gist.github.com/locojay/4950253

And it works wonders.

Basically, the only include flag you really need is '-isystem', '/usr/lib/c++/v1',.

This should also fix #305.

@Valloric
Owner
Valloric commented May 9, 2013

The .ycm_extra_conf.py file linked to from the README is an example file, it's not supposed to cover everything for everyone. The flags that are there by default work for YCM; you're supposed to make an extra conf file yourself that best fits your project (usually by modifying the example file). The easiest way is often to just take the same flags you're passing to gcc/clang when you compile your source files.

YCM adds the path to clang_includes because without those clang-specific includes, semantic code completion would be slow. Clang needs to be able to see the files in that folder to operate correctly, no matter what source code you're compiling.

@Valloric Valloric closed this May 9, 2013
@oblitum
Collaborator
oblitum commented May 9, 2013

@Valloric Does that answer whether it's assumed as issue or not for YCM not to be able to automatically include default included header files (which for flags -std=c++11 and -stdlib=libc++ for example, can be easily verified with echo | clang -std=c++11 -stdlib=libc++ -v -E -x c++ -)?.

Just passing the same flags you're passing to gcc/clang when you compile your source files won't lead to working completion, one must know which headers the compiler include by default for a given set of flags, and include those by hand (IIRC, I had to list even simple /usr/local/include).

@Valloric
Owner

@oblitum Yes, that is troubling... I still can't understand why freaking libclang won't use its default header search paths for code completion like it would for normal compilation. I guess we need a way to pull out the default search paths and append them. Any ideas? We can't call the clang binary because it may not exist on the system. The solution would have to be based on pure libclang.

I know some Clang developers; I'll ask what they think about this.

@oblitum
Collaborator
oblitum commented May 13, 2013

@Valloric Sadly, from libclang solely, I've no idea... But, should this issue just be kept closed? At last, this seems a good place for solutions to be brought and, this is indeed a thing newcomers may stumble upon recurrently.

@oblitum
Collaborator
oblitum commented May 13, 2013

If not reopened, I think it's a good item for FAQ (I've not checked whether there's one such item already).

@Valloric Valloric reopened this May 13, 2013
@Valloric
Owner

Reopening until we figure this out fully.

@pedrovanzella

Could we include a few example ycm_extra_conf.py in the README? This sounds like a sensible solution.

@xunfan
xunfan commented Jun 1, 2013

I just have the similar problems and now I have solved them. If standard headers are not found, the good tool to debug is to use :YcmDiages in vim to see the bug information. You will see what errors are there, such as in xxx.h, yyy.h cannot find. Then you will find yyy.h and add the correct include path to the .ycm_extra_conf.py.

Another thing is sometimes the auto-completion cannot find members of a class I defined. The problem is there are errors in :YcmDiages. It seems sometimes if there are errors, ycm stop auto-competion for you...

@sven-strothoff

On OS X 10.9 with Xcode 5.0.1 you can add

-isystem/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1

to your compile flags to get completion for the STL until there is a proper fix for this issue.
This works if libClang from the Xcode Command Line Tools, i.e. /Library/Developer/CommandLineTools/usr/lib/libclang.dylib is used as external libClang (-DEXTERNAL_LIBCLANG_PATH) when building YCM.

The STL include path can be obtained with (as suggested by @oblitum):
echo | clang -std=c++11 -stdlib=libc++ -v -E -x c++ -

@Valloric
Owner

I've mentioned this issue in the FAQ along with a workaround. I'm looking into a more long-term fix as well, sit tight.

@ofan
ofan commented Nov 21, 2013

I'm writing this just in case someone else runs into the same problem I hit:
I got YCM (partially) working but when I run :YcmDiags , it gave me a list of errors, but syntax and semantic checking seem partially working

error: no member named int8_t in the global namespace

It's in the cstdint header, apparently clang cannot find the proper stdint.h header, even if I add '/usr/include' in the search directories. The problem is the order of '-I /usr/include' and '-I /opt/local/libexec/llvm-3.3/lib/c++/v1', I simply move the '-I /usr/include' parameter to the front, then the problem is solved, and YCM is now working like a charm.

@bfrg
bfrg commented Dec 29, 2013

I'm having the same issues on my linux machine, too. Unfortunately, the suggested workarounds don't work for me. It's not only the std headers that are not found but also other stuff like eigen3. But for some reasons boost headers are found by default without specifying any additional include directories.

@baronleonardo

Comment out '-Wc++98-compat' from your ycm_extra_conf.py

@davits
Contributor
davits commented Apr 5, 2014

I have fixed my standard header version incompatibility problems by turning off clang's default standard header paths and adding correct ones.
Hope this will be helpful.

'-nostdinc++',
'-isystem', '/path_to_gcc/include/c++/4.7.2',
'-isystem', '/path_to_gcc/include/c++/4.7.2/x86_64-redhat-linux',
'-isystem', '/path_to_gcc/include/c++/4.7.2/backward',
@dimatura
dimatura commented Sep 2, 2014

For what it's worth, none of the workarounds to this problem are currently working in my system (Ubuntu 14.04, vim 7.4, clang 3.4, gcc 4.8.2, latest ycm built with install.sh --clang-completer). If someone has YCM working under these conditions I'd like to hear about it.

@taegyunkim

Using Linux Mint 17 Qiana, Vim 7.4, clang 3.4, gcc 4.8.2 and latest ycm build with install.sh --clang--completer, ycm does not suggest std::cout when I type 'std::c'. It only suggests clock() and ctime() even with proper .ycm_extra_conf.py

@RedX2501

Afaik there is no default config file. The one provided is just an example
that needs to be modified.

Please post yours.
Am 18.09.2014 07:11 schrieb "taegyunkim" notifications@github.com:

Using Linux Mint 17 Qiana, Vim 7.4, clang 3.4, gcc 4.8.2 and latest ycm
build with install.sh --clang--completer, ycm does not suggest std::cout
when I type 'std::c'. It only suggests clock() and ctime() even with proper
.ycm_extra_conf.py


Reply to this email directly or view it on GitHub
#303 (comment)
.

@Valloric
Owner

For posterity, here's the relevant (but old) thread on the clang mailing list where I asked about this a ~year ago: http://comments.gmane.org/gmane.comp.compilers.clang.devel/33448

TL;DR: Clang devs: "yeah this sucks; fixing it isn't easy; nobody is working on a fix"

@CIB
CIB commented Nov 15, 2014

Does that answer whether it's assumed as issue or not for YCM not to be able to automatically include default included header files (which for flags -std=c++11 and -stdlib=libc++ for example, can be easily verified with echo | clang -std=c++11 -stdlib=libc++ -v -E -x c++ -)?.

Thanks for that command, adding the directories from there with -isystem to my ycm config fixed my problem. Maybe put this somewhere in the official docs?

EDIT: Oh, it's already there! Nevermind.

@cpradog
cpradog commented Dec 9, 2014

This ycm_extra_conf.py adds the result of echo | clang -v -E -x c++ - to FlagsForFile response plus clang database results.

@scheib scheib pushed a commit to scheib/chromium that referenced this issue Jan 27, 2015
@johnmellor johnmellor + Commit bot YouCompleteMe workaround: explicitly include system include dirs
This patch is a workaround for
Valloric/YouCompleteMe#303

It fixes various issues where standard headers cannot be found, such as:
https://groups.google.com/a/google.com/d/msg/ycm-users/TF9dqx0G0N8/bUQPR0jON80J

Review URL: https://codereview.chromium.org/842053003

Cr-Commit-Position: refs/heads/master@{#312363}
8d6edba
@agauniyal

Is there any temp. fix for this issue , or is someone working on it? I have similar conf. like @dimatura , if someone would make it work with standard libraries it would be great 😞

@shawpenny

hi all.I have the similar problem,my YCM doesnt-work-with-c-standard-library-headers.And i do as you said in the FAQ in the YouCompleteMe.txt.
I call 'echo | clang -v -E -x c++ -' and look at the paths under the '#include <...> search starts here:' heading.
And I take those paths, prepend '-isystem' to each individual path and append them all to
the list of flags you return from your 'FlagsForFile' function in my .ycm_conf_extra.py file:

'-isystem',
'/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8',
'-isystem',
'/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward',
'-isystem',
'/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8',
'-isystem',
'/usr/local/include',
'-isystem',
'/usr/bin/../lib/clang/3.5/include',
'-isystem',
'/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/include',
'-isystem',
'/usr/include/x86_64-linux-gnu',
'-isystem',
'/usr/include',

But the problem still exits.Is there anything else I need do?such as modify the .vimrc file or compile the '.ycm_extra_conf.py' file?
Any help?

@agauniyal

@shawpenny , my current workaround is to use clang++ as default compiler and cmake as default build system. Then I set cmake to out compile commands.json file in build directory on each build and try to build my project. If build is succeeded , then I set compilation database absolute path in ycm_extra_conf.py file. If not , then I have to stay without ycm till I find that bug and build successfully.
The only problem with this approach is , you need to build continously with every file addition and any change so that build folder contains up-to-date compilecommands.json file.

@oblitum
Collaborator
oblitum commented Feb 10, 2015

Which system are you guys using? I use YCM on OS X/Arch/Ubuntu and don't experience this issue.

@agauniyal

@oblitum I'm on Arch too.

@r4nt
r4nt commented Mar 26, 2015

+Valloric - btw, the info in that thread is not correct - libclang does use the driver to locate the include paths; the builtin include paths are a different beast; I'm not sure libclang searches for them correctly relatively to its location. I'm also not sure yet what behavior we really want here.

@agauniyal

So there was a recent update , and this time I built YCM with system clang and now it works flawlessly. However I have no idea how.

@Valloric
Owner

@r4nt Which paths are you specifically referring to? The clang built-in headers which YCM ships (which aren't the issue here) or the include paths to the standard library headers like <vector> etc?

Shipping clang built-in headers isn't really a big deal for YCM at all, but locating the standard library headers is the root of this issue. Every system does something custom, and I know the correct paths for various flavors of Unix/Linux/whatever are hard-coded somewhere in clang-the-binary (I've even seen the source file where they're hard-code a year or so ago). Possibly even libclang, but it doesn't use those paths by default, and I know of no API to tell it to use them.

@r4nt
r4nt commented Mar 26, 2015

@Valloric - I was talking about the standard library paths. libclang does use (and always has used) the clang driver to find the include paths (both builtin and standard library).
With libclang there are 2 interesting things that can go differently from running clang on the command line:

  1. some paths are resolved relatively to the "binary"; in the libclang case I'm not sure that always works correctly; if this is the core issue, we can fix it, but I'd need a reproduction
  2. include order matters; YCM shipping the builtin includes might mess up include order in some cases
@Valloric
Owner

libclang does use (and always has used) the clang driver to find the include paths (both builtin and standard library).

@r4nt Like you said, something then must be special with doing compilation through libclang instead of through clang directly, since there's tons of people on this issue (and my personal experience as well) that show that libclang will often fail to find the standard library paths.

I'll try to put together a repro case for you.

@Valloric
Owner

@r4nt OK, this is now weird. Can't repro this anymore with Goobuntu 14.04 and latest YCM (which pulls in libclang 3.6.0).

Here's my test case. Repro steps are included in the gist.

Did something change in libclang land since this issue was first reported? If so, it fixed this.

I think this might only still be failing on Mac OS X; I'll investigate further.

@oblitum
Collaborator
oblitum commented Mar 26, 2015

I'm happy if it's been solved upstream \o/

@Valloric
Owner

OK, here's the state of the world as it stands today:

On Linux (at least Ubuntu, probably others as well), the libclang from llvm.org is now working fine. It will find paths to the standard library without issues.

On Mac, the libclang from llvm.org is NOT work fine, but neither is the system libclang. After talking with a few clang devs and reading through the relevant clang code, it's apparent that the logic for producing the standard library paths on Mac is just not in libclang (but is in clang).

I'm probably going to put a hack for Mac OS X into ycmd so that this all Just Works.

@Valloric Valloric added a commit to Valloric/ycmd that closed this issue Mar 27, 2015
@Valloric Adding workaround for libclang bug on mac
On Mac OS X, libclang will fail to include the standard header search
paths that clang will. So we add the paths ourselves.

Fixes Valloric/YouCompleteMe#303
11edf12
@Valloric
Owner

OK, I added a workaround for Mac OS X. Other OS's should work fine.

(Windows remains unsupported, as was the case before.)

@ddelnano

How do I pull in your fix on Mac OS X? I installed YCM via Vundle. Will I need to delete and reinstall it? I am trying to use it for C/C++. My YCM compiles everything fine but I get no auto completion unless it is a variable I have previously typed.

@chenyuewu

Here at my Fedora 21 x86_64 machine, I tried using upstream libclang 3.6 from llvm.org and clang 3.5 on my machine to compile ycm. Both work fine. The only issue is that on the #include line, ycm does not help complete the name of standard library header unless their path are explicitly added to .ycm_extra_config.py.

@r4nt
r4nt commented Apr 1, 2015

+chenyuewu - which headers exactly?

@chenyuewu

@r4nt headers like iostream, vector, random, etc.

@radome
radome commented Apr 10, 2015

I'm using the default .ycm_extra_conf.py (latest version) on my OS X 10.10.3 with xcode 6.3. The syntax checker (syntastic) does not recognize C++11 syntax.

@nickhutchinson
Contributor

@Valloric Could you consider an alternative to forcibly adding the MAC_INCLUDE_PATHS via -isystem? This commit means it's no longer possible to have precise control over the include paths YCM passes to libclang on OS X. I've had to revert this commit locally as sometimes the OS X headers are inappropriate for a project (e.g. I'm making use of -target and --sysroot flags for cross-compilation).

@Valloric
Owner

This commit means it's no longer possible to have precise control over the include paths YCM passes to libclang on OS X.

It was never possible to have complete control over the flags that ycmd passes to libclang; for instance, we've always been filtering out flags that tend to crash libclang, slow it down or lead to bad diagnostic output. We've also always been passing an extra --isystem include flag to force inclusion of clang built-in headers that YCM ships.

In other words, this "YCM tweaks flags before passing to libclang" behavior isn't new. We want to make the 99% use-case easy and pain-free; sometimes that means that the 1% use-case is more difficult and it's a price we're willing to pay.

@nickhutchinson
Contributor

@Valloric The difference is that the compiler builtin headers are platform-independent. I'd argue that you should consider a more nuanced approach than forcibly including system headers from the host machine. A heuristic for disabling the forced includes could be the presence of flags like -target x86_64-pc-linux-gnu --sysroot /path/to/my/linux/sysroot.

@Valloric
Owner

@nickhutchinson That sounds like a reasonable heuristic that wouldn't be hard to implement. If you send that as a pull request to ycmd, it would be accepted.

@darlingm
  1. By saying to use the "upstream pre-built libclang" instead of the "system libclang", where does llvm svn trunk source builds fit in? I'm thinking that's the equivalent to "upstream pre-built libclang" in the context that your distribution hasn't messed with it... But I want to clarify this.
  2. It would be cool to change the part of the FAQ from saying "The workaround is to call echo | clang -v -E -x c++ -" to also say if your system has stdlibc++ and you're using "-stdlib=libc++" to instead run "echo | clang -stdlib=libc++ -v -E -x c++ -". The former gives include directories for gcc's stdlibc++, and the latter gives include directories for llvm's libc++. I was adding the given include directories to my CMakeLists.txt as "include_directory(SYSTEM" so they would be in my compilation database, and including the stdlibc++ include directories was causing linker errors, of undefined references to stdlibc++.
  3. I realize instead of adding to CMakeLists.txt, I could have added the directories to my .ycm_extra_conf.py, which would probably avoid the undefined reference linking errors, but them YCM would be still parsing stdlibc++ instead of libc++, which ... I don't know, haven't tried it, maybe it would work in most circumstances, but would be better to avoid.
@Valloric
Owner

By saying to use the "upstream pre-built libclang" instead of the "system libclang", where does llvm svn trunk source builds fit in? I'm thinking that's the equivalent to "upstream pre-built libclang" in the context that your distribution hasn't messed with it... But I want to clarify this.

Your assumption is correct. "Upstream" refers to pristine llvm source. Most distros add patches on top because heaven forbid they upstream their changes. This is why we can't have nice things.

It would be cool to change the part of the FAQ [...]

Good idea, PR welcome! :)

@dragonxlwang

Not sure if this is my specific problem, but I can't find standard library (c or c++) if not adding include path manually.

Running on Scientific Linux 6.7, I am using compiled libclang.so because my glibc is old. And I am using gcc from devetoolset-2, which is in /opt/rh/devetoolset-2.

If not including path such as /usr/include to extra_conf, then the prompt for completion of header file name won't show up. But I can still jump from c/c++ library functions to the source code without any problem. From previous discussion I thought this problem is solved, please let me know if I am missing anything

And here's the output of YcmDebugInfo:

Printing YouCompleteMe debug information...
-- Server has Clang support compiled in: True
-- Clang version: clang version 3.8.0 (tags/RELEASE_380/final)
-- Flags for /home/xwang95/workspace/s3e_scr/test/test.c loaded from /home/xwang95/workspace/s3e_scr/test/.ycm_extra_conf.py:
-- ['-x', 'c', '-Wall', '-Wno-unused-variable', '-std=gnu99', '-resource-dir=/home/xwang95/.vim/bundle/YouCompleteMe/third_party/ycmd/ycmd/../clang_includes']
-- Server running at: http://127.0.0.1:59842
-- Server process ID: 29335
-- Server logfiles:
--   /tmp/ycm_temp/server_59842_stdout.log
--   /tmp/ycm_temp/server_59842_stderr.log

However, on my mac which works correctly, I saw ycm appends lots of system include header paths there. It seems on my linux there is something went wrong already...

@puremourning
Collaborator

You need to pass --gcc-toolchain /opt/rh/devtoolset-2/usr in your flags.

@dragonxlwang

Do you mean add in the python array 'gcc-toolchain' and /opt/rh/devtoolset-2/usr? Thanks!!

@puremourning
Collaborator

When you write your extra conf file, you need to make sure those flags are present if your are on RHEL and using Dev toolset 2. It is beyond the scope of this issue tracker to explain further, as it is covered by the README.

@dragonxlwang

Yes, I have read through (at least I believe) the readme, and the closed thing that i have across which brought me here is this FAQ. However, since my problem is not only C++ but also C, I just wanna make sure that the fix still applies to me (by using echo | clang -v -E -x c++ -). I used that workaround and so far so good...

However, didn't see anything talking about red hat or specifically devtoolset-2. Would appreciate if you point to me :)

@puremourning
Collaborator

I just know you need those flags on RH because I use it every day.

On 8 Apr 2016, at 10:00, dragonxlwang notifications@github.com wrote:

Yes, I have read through (at least I believe) the readme, and the closed thing that i have across which brought me here is this FAQ. However, since my problem is not only C++ but also C, I just wanna make sure that the fix still applies to me (by using echo | clang -v -E -x c++ -). I used that workaround and so far so good...

However, didn't see anything talking about red hat or specifically devtoolset-2. Would appreciate if you point to me :)


You are receiving this because you commented.
Reply to this email directly or view it on GitHub

@dragonxlwang

Thanks!

@mkli90
mkli90 commented Apr 21, 2016 edited

For me the only way to get and std::cout / std::endl working was to add

'-I', '/usr/include/c++/5/'
or
'-I', '/usr/include/c++/5.3.1/'

and the -std=c++11 flag inside my .ycm_extra_conf.py

Using Ubuntu MATE 16.04, g++ 5.3.1 (Ubuntu 5.3.1-14ubuntu2) 20160413

Hope this helps

@dragonxlwang

IMHO there might be a potential problem using -I flag instead of -isystem

@jagerman
jagerman commented May 24, 2016 edited

On Linux (at least Ubuntu, probably others as well), the libclang from llvm.org is now working fine. It will find paths to the standard library without issues.

@Valloric Can you confirm that this is still the case with libclang 3.8? I've noticed the problem showing up recently in Debian testing, and after investigating a little, it seems to coincide with an upgraded version of Debian's ycmd, which started being built against clang 3.8 around the middle of April—and, IIRC, that's around the time standard headers stopped being included properly.

I installed Ubuntu 16.04 (which also has ycmd built against clang 3.8) into a virtual machine to test it--same issue: standard headers are not found by default.

I can apply the workaround to get it to work, but that's a nuisance, particularly since the workaround needs to be updated in every project every time stdlibc++ gets a major version upgrade, which is going to be happening more frequently with GCC's new versioning scheme.

We want to make the 99% use-case easy and pain-free; sometimes that means that the 1% use-case is more difficult and it's a price we're willing to pay.

The current situation on Debian/Ubuntu seems to be failing this goal: even a simple C++ hello world doesn't work properly. If this is something Debian and Ubuntu have screwed up in libclang-3.8, responsibility for fixing it obviously goes there, but if this is an upstream llvm change, this really needs a fix either in ycm or upstream llvm.

@bijancn bijancn pushed a commit to bijancn/YouCompleteMe that referenced this issue Jul 26, 2016
@homu homu Auto merge of #303 - micbou:python-restart-server, r=Valloric
[READY] Fix RestartServer command in Python completer

`RestartServer` subcommand is not working because the `request_data` parameter is not given to the `RestartServer` method. Since this parameter is not used, remove it.

<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/ycmd/303)
<!-- Reviewable:end -->
9164e2e
@agauniyal
agauniyal commented Aug 17, 2016 edited

Not working anymore with libclang 3.8. I've tried various conf, '-isystem' as well as '-I' and putting flags from echo | clang -v -E -x c++ -

@puremourning
Collaborator

If you have a new problem, please raise a new issue, following the instructions in CONTRIBUTING.md

@Hexcles
Hexcles commented Sep 13, 2016

Hi @puremourning , I filed #2330 for the new problem (the root problem is still exactly the same though) as reported by @jagerman (and I can also confirm it), in particular discussing the need for Linux workaround similar to the macOS one. Cheers.

@acherub acherub pushed a commit to acherub/dotfiles that referenced this issue Sep 20, 2016
Ivan Chi Some plugins added
- NERDtree
  * Use F5 to toggle NERDtree

- NERDcommenter
  * ,ca to switch between // and /**/
  * ,cl to use aligned comments
  * ,cA to add comment at the end of line

- vim-indent-guides
  * ,ig to enable the feature

- YouCompleteMe
  * Tried but not yet installed
  * Because the std library cannot autocomplete
  * Valloric/YouCompleteMe#303

- syntastic
  * Disable the plugin because it only compiles one file

- vim-airline

- vim-repeat
- vim-surround
  * ys to add surround environemnt
  * cs to change surround environment

- tagbar
  * Use F7 to open tagbar

- taglist
  * depends on ctags
  * Use F11 to open taglist

- Setup the ruler of git commit message

- Liu

- vim-color
  * for solarized theme
  * also made modifications about the term setting for the theme
  * .dircolors is added for directory theme for solarized
8bb77ea
@cranehuang cranehuang referenced this issue in emacs-china/Spacemacs-rocks Oct 11, 2016
Open

Spacemacs Rocks(3): 打造C/C++ IDE #3

@leofang leofang added a commit to leofang/YCM-Generator that referenced this issue Oct 23, 2016
@leofang leofang Add the workaround from cpradog/.ycm_extra_conf.py@aad88d
In the FAQ of Valloric/YouCompleteMe, there was an issue of C++ standard
library headers not found (Valloric/YouCompleteMe#303) that has been
resolved with a workaround, and @cpradog has kindly implemented it.

However, this workaround has not yet been incorporated into template.py
in rdnetto/YCM-Generator, so adding this becomes the main purpose of
this fork.
062f14b
@leofang leofang added a commit to leofang/YCM-Generator that referenced this issue Oct 23, 2016
@leofang leofang Add the workaround from https://gist.github.com/cpradog/aad88d51001ea…
…83ecfc6

In the FAQ of [Valloric/YouCompleteMe](https://github.com/Valloric/YouCompleteMe),
there was an issue of C++ standard library headers not found (Valloric/YouCompleteMe#303)
that has been resolved with a workaround, and @cpradog has kindly implemented it.

However, this workaround has not yet been incorporated into template.py
in [rdnetto/YCM-Generator](https://github.com/rdnetto/YCM-Generator), so
adding this becomes the main purpose of this fork.
91cc956
@leofang leofang added a commit to leofang/YCM-Generator that referenced this issue Oct 23, 2016
@leofang leofang Add the workaround from https://gist.github.com/cpradog/aad88d51001ea…
…83ecfc6

In the FAQ of https://github.com/Valloric/YouCompleteMe, there was an
issue of C++ standard library headers not found (Valloric/YouCompleteMe#303)
that has been resolved with a workaround, and @cpradog has kindly implemented it.

However, this workaround has not yet been incorporated into template.py
in https://github.com/rdnetto/YCM-Generator, so adding this becomes the
main purpose of this fork.
6f044a6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment