GCC on illumos generates 32-bit object files by default to maintain
backward compatibility, despite 32-bit platforms are no longer
supported. This may cause link errors, since most distros seem to supply
64-bit LLVM in their repositories (verified on OpenIndiana and OmniOS).
This commit adds an ILLUMOS_USE_M64 option, which is turned on by
default, to instruct gcc on illumos to generate 64-bit object files, as
this is usually the desired behaviour.
Example log:
```
15:47:45 indexer1 pipeline.cc:379 I parse /tmp/d/a.c error:1 use of undeclared identifier 'arg'
clang /tmp/d/a.c --gcc-toolchain=/usr -working-directory=/tmp/d/
```
When the rapidjson found by cmake is an older version it defines a
variable RAPIDJSON_INCLUDE_DIRS instead of RapidJSON_INCLUDE_DIRS (#455).
According to #383 we do not want to make these older version work with
ccls. However currently if the rapidjson found by cmake is an older
version that defined RAPIDJSON_INCLUDE_DIRS, then the cmake invocation
still succeeds but any build command will fail because
RapidJSON_INCLUDE_DIRS was never set properly. This makes the cmake
invocation fail with a relevant error message in this event.
Return serverInfo for an initialize request. This helps clients to
identify ccls even when they just connect to a TCP port and allows them
to easily implement server specific functionalities like $ccls/navigate.
Fix a minor issue that an empty included file is not recorded.
Note, we need to skip invalid uid2lid_and_path because
otherwise lid2path may contain invalid entries with lid: 0,
which will cause the file entry with file_id 0 to have an empty path.
The result from clang commandline is something like
/usr/lib/llvm-7/lib/clang/7.0.1
Which means I need to recompile when the clang is upgraded to newer 7.x.x
However the system has a convenient symlink, which is
/usr/include/clang/7.
/usr/include/c++/9 comes before /usr/include in `{clang,gcc} -v -fsyntax-only -xc++ /dev/null`.
target_include_directories(ccls SYSTEM PRIVATE ${RapidJSON_INCLUDE_DIRS})
If ${RapidJSON_INCLUDE_DIRS} resolves to /usr/include, /usr/include will
be shuffled before /usr/include/c++/9 and will cause `#include_next <stdlib.h>`
issues (see https://github.com/MaskRay/ccls/pull/417).
Check if the include directories are already in CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES.
