search

ycm-core / YouCompleteMe

A code-completion engine for Vim
http://ycm-core.github.io/YouCompleteMe/
GNU General Public License v3.0
25.46k stars 2.81k forks source link

Clang will not find definitions in umbrella framework Accelerate #3249

Closed Bautastein closed 5 years ago

Bautastein commented 5 years ago

Issue Prelude

Please complete these steps and check these boxes (by putting an x inside the brackets) before filing your issue:

Thank you for adhering to this process! It ensures your issue is resolved quickly and that neither your nor our time is needlessly wasted.

Issue Details

Provide a clear description of the problem, including the following key questions:

Created XCode project which includes <Accelerate/Accelerate.h> created compile_commands.json based on exact information in XCode build log.

Verified that clang binary succeeds with exactly the same flags.

Ycm complaints about undeclared identifiers. I also tried with an .ycm_extra_conf.py, and the workaround in the FAQ: echo | clang -v -E -x c - etc... didn't work and shouldn't be necessary.

I'd like to point out that I'm working on a personal project that requires libclang, and it does work with exactly the same flags given to clang_parseTranslationUnit2 as you gave to clang on the command line. No need for workarounds with extra -isystem etc, unless those flags are also necessary on the command line. However, this does not work if you extract libclang.dylib out of the containing folder, as you do in YouCompleteMe. If you instead link to libclang.dylib and let it stay inside the downloaded or installed folder, at least the given example below will work. Then there will be no need to mess with other compiler flags than exactly those given on the command line. If you have examples that this doesn't work, please tell me, because I'll need to know for my own project.

So my proposed solution is to not extract the libclang library out of it's containing folder, let the users instead rely on a package manager, keep the downloaded folder from llvm.org somewhere in their system, or possibly copy the whole shebang into the plugin folder.

For completeness, and in case you have examples where the above does not work, I'll complete the form.

Include steps to reproduce here.

1) Create XCode command-line tool 2) Write main file:


#include <stdlib.h>
#include <math.h>
#include <Accelerate/Accelerate.h>

int main(int argc, const char * argv[]) {
    size_t length = 64;
    float *data = calloc(length, sizeof(float));
//    for( size_t i = 0; i < length; i++ )
//        data[ i ] = random_float( -1.0, 1.0 );

    size_t log2Length = log2(length);

    FFTSetup setup = vDSP_create_fftsetup(log2Length, 2);
    DSPSplitComplex inOutData;

    inOutData.realp = data;
    inOutData.imagp = &data[ length >> 1 ];

    vDSP_fft_zrip(setup, &inOutData, 1, log2Length, kFFTDirection_Forward);

    vDSP_destroy_fftsetup(setup);
    free( data );
    return 0;
}

3) Build from command line xcodebuild, and create compile_commands.json or .ycm_extra_conf.py based on flags used in build log.

4) Open file in vim

Include description of a minimal test case, including any actual code required to reproduce the issue.

See above. It may not be necessary to start with an XCode project, as long as you can successfully compile the above file with clang

No reported syntax errors

Include description of the expected behaviour.

All identifiers declared in sub-frameworks, reported as undeclared.

Include description of the observed behaviour, including actual output, screenshots, etc.

Diagnostic data

Output of vim --version

Place the output here, or a link to a gist.

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Aug 17 2018 17:08:16) Included patches: 1-503, 505-680, 682-1283 Compiled by root@apple.com Normal version without GUI. Features included (+) or not (-): +acl +file_in_path -mouse_sgr +tag_old_static -arabic +find_in_path -mouse_sysmouse -tag_any_white +autocmd +float -mouse_urxvt -tcl -balloon_eval +folding +mouse_xterm -termguicolors -browse -footer +multi_byte -terminal +builtin_terms +fork() +multi_lang +terminfo +byte_offset -gettext -mzscheme +termresponse +channel -hangul_input +netbeans_intg +textobjects +cindent +iconv +num64 +timers -clientserver +insert_expand +packages +title -clipboard +job +path_extra -toolbar +cmdline_compl +jumplist -perl +user_commands +cmdline_hist -keymap +persistent_undo +vertsplit +cmdline_info +lambda +postscript +virtualedit +comments -langmap +printer +visual -conceal +libcall -profile +visualextra +cryptv +linebreak +python/dyn +viminfo +cscope +lispindent -python3 +vreplace +cursorbind +listcmds +quickfix +wildignore +cursorshape +localmap +reltime +wildmenu +dialog_con -lua -rightleft +windows +diff +menu +ruby/dyn +writebackup +digraphs +mksession +scrollbind -X11 -dnd +modify_fname +signs -xfontset -ebcdic +mouse +smartindent -xim -emacs_tags -mouseshape +startuptime -xpm +eval -mouse_dec +statusline -xsmp +ex_extra -mouse_gpm -sun_workshop -xterm_clipboard +extra_search -mouse_jsbterm +syntax -xterm_save -farsi -mouse_netterm +tag_binary
system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" defaults file: "$VIMRUNTIME/defaults.vim" fall-back for $VIM: "/usr/share/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X_UNIX -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L/usr/local/lib -o vim -lm -lncurses -liconv -framework Cocoa

Same error with----------------------------:

VIM - Vi IMproved 8.1 (2018 May 18, compiled Nov 25 2018 14:34:50) macOS version Included patches: 1-280 Compiled by Homebrew Huge version with MacVim GUI. Features included (+) or not (-): +acl +farsi +mouse_sgr -tag_any_white +arabic +file_in_path -mouse_sysmouse -tcl +autocmd +find_in_path +mouse_urxvt +termguicolors +autochdir +float +mouse_xterm +terminal -autoservername +folding +multi_byte +terminfo +balloon_eval -footer +multi_lang +termresponse +balloon_eval_term +fork() -mzscheme +textobjects +browse +fullscreen +netbeans_intg +timers ++builtin_terms -gettext +num64 +title +byte_offset -hangul_input +odbeditor +toolbar +channel +iconv +packages +transparency +cindent +insert_expand +path_extra +user_commands +clientserver +job +perl +vartabs +clipboard +jumplist +persistent_undo +vertsplit +cmdline_compl +keymap +postscript +virtualedit +cmdline_hist +lambda +printer +visual +cmdline_info +langmap +profile +visualextra +comments +libcall -python +viminfo +conceal +linebreak +python3 +vreplace +cryptv +lispindent +quickfix +wildignore +cscope +listcmds +reltime +wildmenu +cursorbind +localmap +rightleft +windows +cursorshape +lua +ruby +writebackup +dialog_con_gui +menu +scrollbind -X11 +diff +mksession +signs -xfontset +digraphs +modify_fname +smartindent +xim +dnd +mouse +startuptime -xpm -ebcdic +mouseshape +statusline -xsmp +emacs_tags +mouse_dec -sun_workshop -xterm_clipboard +eval -mouse_gpm +syntax -xterm_save +ex_extra -mouse_jsbterm +tag_binary
+extra_search +mouse_netterm +tag_old_static
system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" 2nd user gvimrc file: "~/.vim/gvimrc" defaults file: "$VIMRUNTIME/defaults.vim" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim" Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe -DMACOS_X -DMACOS_X_DARWIN -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang -L. -L. -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon -lm -lncurses -liconv -framework AppKit -L/usr/local/opt/lua/lib -llua5.3 -fstack-protector -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7m-darwin -lpython3.7m -framework CoreFoundation -framework Ruby

Output of YcmDebugInfo

Place the output here, or a link to a gist.

-- Client logfile: /var/folders/yl/x06n7dl945g9nr4xsqbnmg580000gp/T/ycm_JhYrVz.log -- Server Python interpreter: /usr/bin/python -- Server Python version: 2.7.10 -- Server has Clang support compiled in: True -- Clang version: clang version 7.0.0 (tags/RELEASE_700/final) -- No extra configuration file found -- C-family completer debug information: -- Compilation database path: /Users/pbholmen/Projects/lldb_asm_easy/DebugTestTarget -- Flags: [u'/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang', u'-x', u'c', u'-arch', u'x86_64', u'-fmessage-length=0', u'-fdiagnostics-s how-note-include-stack', u'-fmacro-backtrace-limit=0', u'-std=gnu11', u'-fmodules', u'-gmodules', u'-fmodules-prune-interval=86400', u'-fmodules-prune-after=345600', u'-fbuild-session- file=/var/folders/yl/x06n7dl945g9nr4xsqbnmg580000gp/C/org.llvm.clang/ModuleCache.noindex/Session.modulevalidation', u'-fmodules-validate-once-per-build-session', u'-Wnon-modular-includ e-in-framework-module', u'-Werror=non-modular-include-in-framework-module', u'-Wno-trigraphs', u'-fpascal-strings', u'-Os', u'-fno-common', u'-Wno-missing-field-initializers', u'-Wno-m issing-prototypes', u'-Werror=return-type', u'-Wdocumentation', u'-Wunreachable-code', u'-Werror=deprecated-objc-isa-usage', u'-Werror=objc-root-class', u'-Wno-missing-braces', u'-Wpar entheses', u'-Wswitch', u'-Wunused-function', u'-Wno-unused-label', u'-Wno-unused-parameter', u'-Wunused-variable', u'-Wunused-value', u'-Wempty-body', u'-Wuninitialized', u'-Wconditio nal-uninitialized', u'-Wno-unknown-pragmas', u'-Wno-shadow', u'-Wno-four-char-constants', u'-Wno-conversion', u'-Wconstant-conversion', u'-Wint-conversion', u'-Wbool-conversion', u'-We num-conversion', u'-Wno-float-conversion', u'-Wnon-literal-null-conversion', u'-Wobjc-literal-conversion', u'-Wshorten-64-to-32', u'-Wpointer-sign', u'-Wno-newline-eof', u'-isysroot', u'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk', u'-fasm-blocks', u'-fstrict-aliasing', u'-Wdeprecated-declarations', u'-mmacosx- version-min=10.14', u'-g', u'-fvisibility=hidden', u'-Wno-sign-conversion', u'-Winfinite-recursion', u'-Wcomma', u'-Wblock-capture-autoreleasing', u'-Wstrict-prototypes', u'-Wno-semico lon-before-method-body', u'-Wunguarded-availability', u'-iquote', u'/Users/pbholmen/Projects/lldb_asm_easy/build/lldb_asm_easy.build/Release/DebugTestTarget.build/DebugTestTarget-gener ated-files.hmap', u'-I/Users/pbholmen/Projects/lldb_asm_easy/build/lldb_asm_easy.build/Release/DebugTestTarget.build/DebugTestTarget-own-target-headers.hmap', u'-I/Users/pbholmen/Proje cts/lldb_asm_easy/build/lldb_asm_easy.build/Release/DebugTestTarget.build/DebugTestTarget-all-target-headers.hmap', u'-iquote', u'/Users/pbholmen/Projects/lldb_asm_easy/build/lldbasm easy.build/Release/DebugTestTarget.build/DebugTestTarget-project-headers.hmap', u'-I/Users/pbholmen/Projects/lldb_asm_easy/build/Release/include', u'-I/Users/pbholmen/Projects/lldb_asm _easy/build/lldb_asm_easy.build/Release/DebugTestTarget.build/DerivedSources/x86_64', u'-I/Users/pbholmen/Projects/lldb_asm_easy/build/lldb_asm_easy.build/Release/DebugTestTarget.build /DerivedSources', u'-F/Users/pbholmen/Projects/lldb_asm_easy/build/Release', u'-resource-dir=/Users/pbholmen/.vim/bundle/YouCompleteMe/third_party/ycmd/clang_includes', u'-fspell-check ing'] -- Translation unit: /Users/pbholmen/Projects/lldb_asm_easy/DebugTestTarget/main.c -- Server running at: http://127.0.0.1:52228 -- Server process ID: 13547 -- Server logfiles: -- /var/folders/yl/x06n7dl945g9nr4xsqbnmg580000gp/T/ycmd_52228_stdout_5elGnH.log -- /var/folders/yl/x06n7dl945g9nr4xsqbnmg580000gp/T/ycmd_52228_stderr_lLb_Tn.log

Contents of YCM, ycmd and completion engine logfiles

Add let g:ycm_log_level = 'debug' to vimrc, restart Vim, reproduce the issue, and include link here to a gist containing the entire logfiles for ycm, ycmd and any completer logfiles listed by :YcmToggleLogs.

ycm_JhYrVz.log: 2018-11-28 13:54:21,607 - ERROR - HTTPConnectionPool(host='127.0.0.1', port=52228): Max retries exceeded with url: /ready (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x11039cf90>: Failed to establish a new connection: [Errno 61] Connection refused',))

ycmd_52228_stderr_lLb_Tn.log: 2018-11-28 13:54:21,780 - INFO - Adding buffer identifiers for file: /Users/pbholmen/Projects/lldb_asm_easy/DebugTestTarget/main.c 2018-11-28 13:54:22,140 - INFO - Received filetype completion available request 2018-11-28 13:54:33,994 - INFO - Received debug info request 2018-11-28 13:55:38,599 - INFO - Received debug info request 2018-11-28 13:57:07,491 - INFO - Received debug info request 2018-11-28 13:57:15,628 - INFO - Received debug info request

ycmd_52228_stdout_5elGnH.log: serving on http://localhost:52228

OS version, distribution, etc.

Include system information here.

macOS mojave 10.14.1

Output of build/install commands

Include link to a gist containing the invocation and entire output of install.py if reporting an installation issue.

bstaletic commented 5 years ago

The problem is that Mojave broke YCM and we can't find the system headers any more. You can do one of two things:

Since this has been reported many times, I'll close this. For further questions, ask on https://gitter.im/Valloric/YouCompleteMe

puremourning commented 5 years ago

Well, we know that there is a problem with finding system headers in Mojave a sweatshirt Boris pointed out. And we have no intention of supporting arbitrary libclang installations.

That said it is true that the compiler-relative path stuff might work in some installations and that is why we have system-libclang option. but we don’t actually want or need user sof ycmd to have a complete clang installation. This also shouldn’t be necessary.

Hopefully solving the cmake/sysroot issue (however we might do that) would resolve this too.

Thanks for the detailed report though, the fact that your tool is not having he same issues is useful data point. But could I ask, in your tool, which libclang install did you link against on your OS? The one on Xcode? Or e.g. homebrew?

Bautastein commented 5 years ago

In my own tool I am linking against the downloaded pre-built binaries, exactly the ones your installation guide points to, and not some arbitrary libclang installation: http://releases.llvm.org/download.html

What I am proposing is to use the library the way it is intended. It expects to find certain files in this folder hierarchy, and when the libclang.dylib file is extracted out of this hierarchy, it fails.

I see you have been having these problems before, with c++ header files, and found workaround hacks for that. Did you try not extracting the dylib files instead? My tool needs no workaround hacks for that either, but needs the same workaround as yours if you extract the libclang.dylib file.

As per clang docs, the very purpose is that you can supply the same flags to the libs as to the clang command line tool. For that to work, you must use the library the way it is intended, rather than running into new problems each time and finding new workarounds.

Den ons. 28. nov. 2018 kl. 18:23 skrev Ben Jackson <notifications@github.com

:

Well, we know that there is a problem with finding system headers in Mojave a sweatshirt Boris pointed out. And we have no intention of supporting arbitrary libclang installations.

That said it is true that the compiler-relative path stuff might work in some installations and that is why we have system-libclang option. but we don’t actually want or need user sof ycmd to have a complete clang installation. This also shouldn’t be necessary.

Hopefully solving the cmake/sysroot issue (however we might do that) would resolve this too.

Thanks for the detailed report though, the fact that your tool is not having he same issues is useful data point. But could I ask, in your tool, which libclang install did you link against on your OS? The one on Xcode? Or e.g. homebrew?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Valloric/YouCompleteMe/issues/3249#issuecomment-442531302, or mute the thread https://github.com/notifications/unsubscribe-auth/ABi3hMPwi-MvGclFnXrwgmVpB_opyCaxks5uzsZzgaJpZM4Y3rlQ .

Bautastein commented 5 years ago

In other words I have probably found the answer to the many things you wonder about in your FAQ's, source codes and issue tracker, with wordings such as:

# These are the standard header search paths that clang will use on Mac BUT
# libclang won't, for unknown reasons.

Now you know the reason.

Regarding -isysroot, I had already tried both with and without, to no avail. I have also tried "-DUSE_SYSTEM_LIBCLANG=ON", from a clean install, but it still copies the libclang.dylib into the bundle directory, still does not work with the same flags as on the command line, neither with your proposed workarounds, and it does not let you use downloaded binaries but instead starts to search in /usr/local/ etc... so clearly this is no solution.

Keep finding new workarounds when there is a correct solution is not a good long term plan.

Bautastein commented 5 years ago

Sorry, not going to bother you any more, I promise. I just wanted to say you don't necessarily have to copy the entire llvm+clang prebuilt binaries folder, probably all you need to do is figure out what other files in the hierarchy libclang relies on, knowing that while it seems the llvm root folder is relocatable, the libclang dynamic library is NOT relocatable relative to the other files it relies on. The clang project might have docs about that, or you can request it.

But in the source files you write that you expect this to be fixed by the clang devs, and it won't because it's not a bug, it's just that the lib isn't intended to be used the way you use it. Just because you can make it work other ways, does mean it's the right way.

puremourning commented 5 years ago

Ok chill. I think you made your point.

I’m locking this thread because I think it has sufficient discussion for now. Perhaps we will have a think about the compromises here.

Meanwhile you can make YCM work for you as Boris said, or not. We won’t be offended.

puremourning commented 5 years ago

Re open as the point stands that the system library issue may indeed be related to relocation of libclang at least in some platforms