[cfe-dev] Some error in clangd

yus via cfe-dev cfe-dev at lists.llvm.org
Thu Apr 4 02:14:17 PDT 2019 

HI,

Sorry, another similar problem.
In the CDB generated by cmake,
all source file in the contracts, use wrong command.
for example
{
  "directory": "/root/workspace/eos4/build/contracts/eosio.system",

         "command": "/usr/bin/clang++-4.0
 -I/root/workspace/eos4/contracts/eosio.system/..   -Wall
-Wno-invalid-partial-specialization -O3 -DNDEBUG   -std=gnu++14 -o
CMakeFiles/eosio.system.tmp.dir/eosio.system.cpp.o -c
/root/workspace/eos4/contracts/eosio.system/eosio.system.cpp",
  "file": "/root/workspace/eos4/contracts/eosio.system/eosio.system.cpp"
},
the right command should be :
/root/opt/wasm/bin/clang -emit-llvm -O3 --std=c++14 --target=wasm32
-ffreestanding -nostdlib -nostdlibinc -fno-threadsafe-statics -fno-rtti
-fno-exceptions -c
/root/workspace/eos4/contracts/eosio.system/eosio.system.cpp -o
eosio.system.cpp.bc -Weverything -Wno-c++98-compat -Wno-old-style-cast
-Wno-vla -Wno-vla-extension -Wno-c++98-compat-pedantic
-Wno-missing-prototypes -Wno-missing-variable-declarations -Wno-packed
-Wno-padded -Wno-c99-extensions -Wno-documentation-unknown-command -I
/root/workspace/eos4/contracts -I
/root/workspace/eos4/externals/magic_get/include -isystem
/root/workspace/eos4/contracts/libc++/upstream/include -isystem
/root/workspace/eos4/contracts/musl/upstream/include -isystem
/root/opt/boost/include -isystem
/root/workspace/eos4/contracts/libc++/upstream/include -isystem
/root/workspace/eos4/contracts/musl/upstream/include -isystem
/root/opt/boost/include

I have modified some in the CDB, but there are too many file in contracts.
Is there any simple way to fix it.
Thanks.

Brs,
Su Yu

yus <suyu.nu at gmail.com> 于2019年4月3日周三 下午3:56写道：

> HI,
>
> It works.
> Thank you very much.
>
> Brs,
> Su Yu
>
> Sam McCall <sammccall at google.com> 于2019年4月3日周三 下午3:17写道：
>
>> Add an entry to compile_commands.json:
>> {
>>   "file": ".../libraries/chain/include/eosio/chain/types.hpp",
>>   "directory": ".../build/libraries/chain",
>>   "command": "/usr/bin/clang++-4.0 ... -c
>> .../libraries/chain/include/eosio/chain/types.hpp"
>> }
>>
>> where the ... path is adjusted for your system, and the command is taken
>> from the entry from some other relevant file (e.g. abi_serializer.cpp)
>>
>> You'll also need to prevent your build system from overwriting this
>> change.
>>
>> ---
>>
>> Another thought on a proper fix: we know that types.hpp is a good match
>> for resource_limits.hpp in the same directory, which in turn is a good
>> match for resource_limits.cpp. This transitive connection might be a useful
>> signal. Unfortunately we don't know that resource_limits.hpp exists when
>> loading the interpolating CDB. Maybe listing the parent directory of
>> types.hpp is viable though.
>>
>> On Wed, Apr 3, 2019 at 4:30 AM yus <suyu.nu at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Many thanks for your analysis and suggestion.
>>> For you suggestion, I know what to do but don't know how to do.
>>>
>>> Can you give some details about the option 1:
>>> - adding an explicit compile command for types.hpp, and avoid
>>> overwriting it,
>>> How to do it.
>>>
>>> Thanks.
>>>
>>> Brs,
>>> Su Yu
>>>
>>> Sam McCall <sammccall at google.com> 于2019年4月3日周三 上午12:24写道：
>>>
>>>> Indeed, the heuristics are valuing base filenames over directory
>>>> structure match in this case:
>>>>
>>>> sed -i s%/root/workspace/eos4%$PWD%g compile_commands.json
>>>> mkdir -p libraries/chain/include/eosio/chain
>>>> touch
>>>> libraries/chain/include/eosio/chain/{types,resource_limits,zzz}.hpp
>>>>
>>>> clang-check -debug-only=interpolate
>>>> libraries/chain/include/eosio/chain/types.hpp
>>>> interpolate: chose .../libraries/wasm-jit/Source/IR/*Types*.cpp as
>>>> proxy for .../libraries/chain/include/eosio/chain/*types*.hpp
>>>> preferring c++ score=2
>>>> (this is a bad result: prefer e.g.
>>>> .../libraries/chain/abi_serializer.cpp)
>>>>
>>>> clang-check -debug-only=interpolate
>>>> libraries/chain/include/eosio/chain/resource_limits.hpp
>>>> interpolate: chose .../libraries/*chain*/*resource_limits*.cpp as
>>>> proxy for .../libraries/chain/include/eosio/*chain*/*resource_limits*.hpp
>>>> preferring c++ score=3
>>>> (this is a good result)
>>>>
>>>> clang-check -debug-only=interpolate
>>>> libraries/chain/include/eosio/chain/zzz.hpp
>>>> interpolate: chose .../libraries/*chain*/abi_serializer.cpp as proxy
>>>> for .../libraries/chain/include/eosio/*chain*/zzz.hpp preferring c++
>>>> score=1
>>>> (this is a good result)
>>>>
>>>> --- details ---
>>>>
>>>> Points are awarded to entries in compile_commands:
>>>>  - 2 points for filename match without extension (1 for prefix match)
>>>>  - up to 3 points for directory structure match (1 for each of last 2
>>>> segments, 1 for the rest)
>>>>
>>>> For files in this directory, the relevant directory structure parts are
>>>> .../libraries/chain/include eosio chain.
>>>> So:
>>>>   - anything under ".../libraries/chain/include" would get 1 point
>>>> (there are no cpp files there)
>>>>   - anything with "eosio" in the last 4 directory segments gets 1 point
>>>> (no matches)
>>>>   - anything with "chain" in the last 4 directory segments gets 1 point
>>>> (*1 point for sources in "chain" subproject*)
>>>> With this directory structure, we do manage to pair headers/sources in
>>>> the same project, but we only give a 1 point bonus for doing so, and so the
>>>> 2 point bonus for matching basename can take precedence.
>>>>
>>>> --- how to fix in clang ---
>>>>
>>>> We only need to tweak the scores here by one point: a tie will be
>>>> broken in favor of the longest prefix match, which would be when sources
>>>> are in the same subproject with this directory structure.
>>>>
>>>> One option is to make the name match worth less: 0.5/1 rather than 1/2
>>>> points, though I do worry this will break some cases in the other direction.
>>>>
>>>> Another option is to recognize this directory structure match as
>>>> particularly good, and boost it more - 1 seems relatively low for e.g.
>>>> .../chain/abi_serializer.cpp matching .../chain/types.hpp where it's the
>>>> immediate parent directories that match.
>>>> This would be somewhat involved: the index data structure doesn't
>>>> currently capture where the word "chain" appeared within the cpp filename.
>>>>
>>>> I'll look into this...
>>>>
>>>> --- how to work around ---
>>>>
>>>> The only thing I can suggest is to change your compilation database,
>>>> either:
>>>>  - adding an explicit compile command for types.hpp, and avoid
>>>> overwriting it, or
>>>>  - only generate the CDB for a smaller subset of the project that
>>>> avoids Types.cpp
>>>>
>>>> On Mon, Apr 1, 2019 at 6:37 PM Sam McCall <sammccall at google.com> wrote:
>>>>
>>>>> Apologies, missed the attachment in the original email. Will look in
>>>>> the morning!
>>>>>
>>>>> On Mon, Apr 1, 2019 at 2:17 PM Sam McCall <sammccall at google.com>
>>>>> wrote:
>>>>>
>>>>>> Hi! Sorry the heuristics aren't working here.
>>>>>> The most likely thing is the bare name "types" is matching some *.cpp
>>>>>> file from a base library, and we're weighing that too heavily and the
>>>>>> directory not heavily enough. This is probably due to heuristics tuned for
>>>>>> the LLVM project itself, which has few dependencies and parallel
>>>>>> source/include trees.
>>>>>> Can you attach compile_commands.json please?
>>>>>>
>>>>>> On Mon, Apr 1, 2019 at 11:24 AM Ilya Biryukov <ibiryukov at google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I don't think there's any simple solution to this. You could try
>>>>>>> patching your 'compile_commands.json' to add the header files in there, but
>>>>>>> CMake won't do this automatically for you.
>>>>>>> I believe the following project on GitHub tries to do something
>>>>>>> similar, but I haven't tried it myself:
>>>>>>> https://github.com/Sarcasm/compdb
>>>>>>>
>>>>>>>
>>>>>>> +Sam McCall <sammccall at google.com>, now that you're back from
>>>>>>> leave, any ideas for improving the heuristics to find proper matching .cpp
>>>>>>> files in more cases?
>>>>>>>
>>>>>>> On Mon, Apr 1, 2019 at 11:11 AM yus <suyu.nu at gmail.com> wrote:
>>>>>>>
>>>>>>>> Excuse me, is there any solution for my problem?
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> yus <suyu.nu at gmail.com> 于2019年3月23日周六 上午9:40写道：
>>>>>>>>
>>>>>>>>> HI,
>>>>>>>>>
>>>>>>>>> Got it.
>>>>>>>>> So my problem has no relationship with front-end vim-YoucompleteMe
>>>>>>>>> I just need to wait for your solution or workaround.
>>>>>>>>>
>>>>>>>>> Thanks for your help.
>>>>>>>>>
>>>>>>>>> Brs,
>>>>>>>>> Su Yu
>>>>>>>>>
>>>>>>>>> Ilya Biryukov <ibiryukov at google.com> 于2019年3月22日周五 下午8:43写道：
>>>>>>>>>
>>>>>>>>>> On Fri, Mar 22, 2019 at 12:41 PM yus <suyu.nu at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> By the way,
>>>>>>>>>>> If a header has no source file (*.cpp), how it been handled.
>>>>>>>>>>>
>>>>>>>>>> In that case we would fallback to something like `clang -xc++
>>>>>>>>>> test.hpp`.
>>>>>>>>>> But that almost never happens, our heuristics will always try to
>>>>>>>>>> pick some cpp file first.
>>>>>>>>>> E.g. in the extreme case when compile_commands.json has just a
>>>>>>>>>> single file, we will take the compile command from that file for
>>>>>>>>>> *all* headers we encounter.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Brs,
>>>>>>>>>>> Su Yu
>>>>>>>>>>>
>>>>>>>>>>> yus <suyu.nu at gmail.com> 于2019年3月22日周五 下午7:37写道：
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Many thanks for your prompt answer.
>>>>>>>>>>>> It's an open source project.
>>>>>>>>>>>> But it's a little difficult to build. It has many dependency
>>>>>>>>>>>> Hope it can help.
>>>>>>>>>>>> https://github.com/EOSIO/eos
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Brs,
>>>>>>>>>>>> Su Yu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Ilya Biryukov <ibiryukov at google.com> 于2019年3月22日周五 下午5:18写道：
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Su,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since compile_commands.json only contains compile commands for
>>>>>>>>>>>>> .cpp files, we use a heuristics-based approach to infer compile commands
>>>>>>>>>>>>> for headers.
>>>>>>>>>>>>> More precisely, based on the path to the header file we try to
>>>>>>>>>>>>> guess the best .cpp file for a header (e.g. an implementation file) and
>>>>>>>>>>>>> pick the compile command from it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In your case, we fail to guess a good compile command. I don't
>>>>>>>>>>>>> know of a good workaround, unfortunately.
>>>>>>>>>>>>> +Sam McCall <sammccall at google.com> is the author of this
>>>>>>>>>>>>> approach, he might have ideas on how to fix this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is the project you're working on open-source? If so, could you
>>>>>>>>>>>>> provide a link to the source code? If not, compilation database should also
>>>>>>>>>>>>> be enough to reproduce.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Mar 21, 2019 at 10:41 PM yus via cfe-dev <
>>>>>>>>>>>>> cfe-dev at lists.llvm.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> I encounter an error in clangd
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I[12:49:12.197] Updating file
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/include/eosio/chain/types.hpp with
>>>>>>>>>>>>>> command*
>>>>>>>>>>>>>> [/root/workspace/eos4/build/libraries/wasm-jit/Source/IR] */usr/bin/clang++-4.0
>>>>>>>>>>>>>> -D ENABLE_SIMD_PROTOTYPE=0 -D ENABLE_THREADING_PROTOTYPE=0 -D
>>>>>>>>>>>>>> IR_API=DLL_EXPORT -D PRETEND_32BIT_ADDRESS_SPACE=0 -D WAVM_METRICS_OUTPUT=0
>>>>>>>>>>>>>> -I /root/workspace/eos4/libraries/wasm-jit/Include -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/wasm-jit/Include/IR -Wall
>>>>>>>>>>>>>> -Wno-invalid-partial-specialization -O3 -D NDEBUG -c -std=gnu++14
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/include/eosio/chain/types.hpp
>>>>>>>>>>>>>> -resource-dir=/root/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/clang/lib/clang/7.0.0
>>>>>>>>>>>>>> V[12:49:12.199] Preamble for file
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/include/eosio/chain/types.hpp cannot
>>>>>>>>>>>>>> be reused. Attempting to rebuild it.
>>>>>>>>>>>>>> V[12:49:12.238] Built preamble of size 213512 for file
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/include/eosio/chain/types.hpp
>>>>>>>>>>>>>> I[12:49:12.242] Dropped diagnostic outside main file: : too
>>>>>>>>>>>>>> many errors emitted, stopping now
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> some other file in same folder update correctly
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I[12:49:03.898] Updating file
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/include/eosio/chain/resource_limits.hpp
>>>>>>>>>>>>>> with command *[/root/workspace/eos4/build/libraries/chain] */usr/bin/clang++-4.0
>>>>>>>>>>>>>> -I /root/workspace/eos4/libraries/chain/include -I
>>>>>>>>>>>>>> /root/workspace/eos4/build/libraries/chain/include -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/../wasm-jit/Include -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/../../externals/binaryen/src -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/utilities/include -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/utilities/../wasm-jit/Include -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/fc/include -I /root/opt/boost/include -I
>>>>>>>>>>>>>> /usr/local/include -I /root/workspace/eos4/libraries/fc/vendor/websocketpp
>>>>>>>>>>>>>> -I /root/workspace/eos4/libraries/chainbase/include -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/wasm-jit/Source/Runtime/../../../chain/include
>>>>>>>>>>>>>> -I /root/workspace/eos4/libraries/softfloat/source/include -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/softfloat/source/8086-SSE -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/softfloat/build/Linux-x86_64-GCC -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/builtins -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/builtins../softfloat/source/include -Wall
>>>>>>>>>>>>>> -Wno-invalid-partial-specialization -O3 -D NDEBUG -c -std=gnu++14
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/include/eosio/chain/resource_limits.hpp
>>>>>>>>>>>>>> -resource-dir=/root/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/clang/lib/clang/7.0.0
>>>>>>>>>>>>>> V[12:49:03.901] Preamble for file
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/include/eosio/chain/resource_limits.hpp
>>>>>>>>>>>>>> cannot be reused. Attempting to rebuild it.
>>>>>>>>>>>>>> V[12:49:10.676] <<<
>>>>>>>>>>>>>> {"id":"3","jsonrpc":"2.0","method":"textDocument/definition","params":{"position":{"character":51,"line":53},"textDocument":{"uri":"file:///root/workspace/eos4/libraries/chain/include/eosio/chain/resource_limits.hpp"}}}
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't know why, and what's the difference. why the flags
>>>>>>>>>>>>>> are different.
>>>>>>>>>>>>>> How to fix the problem
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> root at 39470746ee31:~/workspace/eos4# /usr/bin/clang++-4.0 -D
>>>>>>>>>>>>>> ENABLE_SIMD_PROTOTYPE=0 -D ENABLE_THREADING_PROTOTYPE=0 -D
>>>>>>>>>>>>>> IR_API=DLL_EXPORT -D PRETEND_32BIT_ADDRESS_SPACE=0 -D WAVM_METRICS_OUTPUT=0
>>>>>>>>>>>>>> -I /root/workspace/eos4/libraries/wasm-jit/Include -I
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/wasm-jit/Include/IR -Wall
>>>>>>>>>>>>>> -Wno-invalid-partial-specialization -O3 -D NDEBUG -c -std=gnu++14
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/include/eosio/chain/types.hpp
>>>>>>>>>>>>>> -resource-dir=/root/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/clang/lib/clang/7.0.0
>>>>>>>>>>>>>> /root/workspace/eos4/libraries/chain/include/eosio/chain/types.hpp:6:10:
>>>>>>>>>>>>>> fatal error: 'eosio/chain/name.hpp' file not found
>>>>>>>>>>>>>> #include <eosio/chain/name.hpp>
>>>>>>>>>>>>>>          ^~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>>>>>> 1 error generated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> attach the error and compilation database
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Brs
>>>>>>>>>>>>>> Su Yu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> cfe-dev mailing list
>>>>>>>>>>>>>> cfe-dev at lists.llvm.org
>>>>>>>>>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Ilya Biryukov
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Regards,
>>>>>>>>>> Ilya Biryukov
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Ilya Biryukov
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190404/18ea8e9e/attachment.html>

More information about the cfe-dev mailing list