Update C-family documentation

This commit is contained in:
micbou 2018-07-24 01:58:28 +02:00
parent 8a911c1a80
commit 52c022708c
No known key found for this signature in database
GPG Key ID: C7E8FD1F3BDA1E05
2 changed files with 68 additions and 64 deletions

View File

@ -998,9 +998,8 @@ documentation][compdb]. In short:
[`.ycm_extra_conf.py`](#option-2-provide-the-flags-manually) below.
If no [`.ycm_extra_conf.py`](#option-2-provide-the-flags-manually) is found,
and no [`ycm_global_ycm_extra_conf`](#the-gycm_global_ycm_extra_conf-option) is
configured, YouCompleteMe automatically tries to load a compilation database if
one is found.
YouCompleteMe automatically tries to load a compilation database if there is
one.
YCM looks for a file named `compile_commands.json` in the directory of the
opened file or in any directory above it in the hierarchy (recursively); when
@ -1027,7 +1026,7 @@ directory.
If you don't have a compilation database, or aren't able to generate one,
you have to tell YouCompleteMe how to compile your code some other way.
Every c-family project is different. It is not possible for YCM to guess what
Every C-family project is different. It is not possible for YCM to guess what
compiler flags to supply for your project. Fortunately, YCM provides a mechanism
for you to generate the flags for a particular file with _arbitrary complexity_.
This is achieved by requiring you to provide a Python module which implements a
@ -1036,13 +1035,17 @@ compiler flags to use to compile that file.
YCM looks for a `.ycm_extra_conf.py` file in the directory of the opened file or
in any directory above it in the hierarchy (recursively); when the file is
found, it is loaded (only once!) as a Python module. YCM calls a `FlagsForFile`
found, it is loaded (only once!) as a Python module. YCM calls a `Settings`
method in that module which should provide it with the information necessary to
compile the current file. You can also provide a path to a global
`.ycm_extra_conf.py` file, which will be used as a fallback. To prevent the
execution of malicious code from a file you didn't write YCM will ask you once
per `.ycm_extra_conf.py` if it is safe to load. This can be disabled and you can
white-/blacklist files. See the _Options_ section for more details.
compile the current file. You can also provide a path to a global configuration
file with the
[`g:ycm_global_ycm_extra_conf`](#the-gycm_global_ycm_extra_conf-option) option,
which will be used as a fallback. To prevent the execution of malicious code
from a file you didn't write YCM will ask you once per `.ycm_extra_conf.py` if
it is safe to load. This can be disabled and you can white-/blacklist files. See
the [`g:ycm_confirm_extra_conf`](#the-gycm_confirm_extra_conf-option) and
[`g:ycm_extra_conf_globlist`](#the-gycm_extra_conf_globlist-option) options
respectively.
This system was designed this way so that the user can perform any arbitrary
sequence of operations to produce a list of compilation flags YCM should hand
@ -1053,25 +1056,25 @@ This is so that the correct language is detected, particularly for header files.
Common values are `-x c` for C, `-x c++` for C++, `-x objc` for Objective-C, and
`-x cuda` for CUDA.
To give you an impression, if your c++ project is trivial, and your usual
To give you an impression, if your C++ project is trivial, and your usual
compilation command is: `g++ -Wall -Wextra -Werror -o FILE.o FILE.cc`, then the
following `.ycm_extra_conf.py` is enough to get semantic analysis from
YouCompleteMe:
```python
def FlagsForFile( filename, **kwargs ):
def Settings( **kwargs ):
return {
'flags': [ '-x', 'c++', '-Wall', '-Wextra', '-Werror' ],
}
```
As you can see from the trivial example, YCM calls the `FlagsForFile` method,
passing it the file name. The `**kwargs` is for advanced users and can usually
be ignored. The `FlagsForFile` function returns a dictionary with a single
element `'flags'`. This element is a `list` of compiler flags to pass to
libclang for the file `filename`. That's it! This is actually enough for most
projects, but for complex projects it is not uncommon to integrate directly with
an existing build system using the full power of the Python language.
As you can see from the trivial example, YCM calls the `Settings` method which
returns a dictionary with a single element `'flags'`. This element is a `list`
of compiler flags to pass to libclang for the current file. The absolute path of
that file is accessible under the `filename` key of the `kwargs` dictionary.
That's it! This is actually enough for most projects, but for complex projects
it is not uncommon to integrate directly with an existing build system using the
full power of the Python language.
For a more elaborate example,
[see YCM's own `.ycm_extra_conf.py`][flags_example]. You should be able to use
@ -1920,14 +1923,14 @@ Supported in filetypes: `cs, go, java, javascript, python, rust, typescript`
#### The `ClearCompilationFlagCache` subcommand
YCM caches the flags it gets from the `FlagsForFile` function in your
`ycm_extra_conf.py` file unless you return them with the `do_cache` parameter
YCM caches the flags it gets from the `Settings` function in your
`.ycm_extra_conf.py` file unless you return them with the `do_cache` parameter
set to `False`. It also caches the flags extracted from the compilation
database. The cache is in memory and is never invalidated (unless you restart
the server with the `:YcmRestartServer` command).
This command clears that cache entirely. YCM will then re-query your
`FlagsForFile` function or your compilation database as needed in the future.
`Settings` function or your compilation database as needed in the future.
Supported in filetypes: `c, cpp, objc, objcpp, cuda`
@ -2471,28 +2474,28 @@ let g:ycm_seed_identifiers_with_syntax = 0
### The `g:ycm_extra_conf_vim_data` option
If you're using semantic completion for C-family files, this option might come
handy; it's a way of sending data from Vim to your `FlagsForFile` function in
handy; it's a way of sending data from Vim to your `Settings` function in
your `.ycm_extra_conf.py` file.
This option is supposed to be a list of VimScript expression strings that are
evaluated for every request to the [ycmd server][ycmd] and then passed to your
`FlagsForFile` function as a `client_data` keyword argument.
`Settings` function as a `client_data` keyword argument.
For instance, if you set this option to `['v:version']`, your `FlagsForFile`
For instance, if you set this option to `['v:version']`, your `Settings`
function will be called like this:
```python
# The '704' value is of course contingent on Vim 7.4; in 7.3 it would be '703'
FlagsForFile(filename, client_data = {'v:version': 704})
# The '801' value is of course contingent on Vim 8.1; in 8.0 it would be '800'
Settings( ..., client_data = { 'v:version': 801 } )
```
So the `client_data` parameter is a dictionary mapping Vim expression strings to
their values at the time of the request.
The correct way to define parameters for your `FlagsForFile` function:
The correct way to define parameters for your `Settings` function:
```python
def FlagsForFile(filename, **kwargs):
def Settings( **kwargs ):
```
You can then get to `client_data` with `kwargs['client_data']`.
@ -3326,7 +3329,7 @@ reading.
The workaround is to call `echo | clang -v -E -x c++ -` and look at the
paths under the `#include <...> search starts here:` heading. You should 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 your
the list of flags you return from your `Settings` function in your
`.ycm_extra_conf.py` file.
See [issue #303][issue-303] for details.
@ -3467,7 +3470,7 @@ This software is licensed under the [GPL v3 license][gpl].
[vim]: http://www.vim.org/
[syntastic]: https://github.com/scrooloose/syntastic
[lightline]: https://github.com/itchyny/lightline.vim
[flags_example]: https://raw.githubusercontent.com/Valloric/ycmd/3ad0300e94edc13799e8bf7b831de8b57153c5aa/cpp/ycm/.ycm_extra_conf.py
[flags_example]: https://raw.githubusercontent.com/Valloric/ycmd/66030cd94299114ae316796f3cad181cac8a007c/.ycm_extra_conf.py
[compdb]: http://clang.llvm.org/docs/JSONCompilationDatabase.html
[subsequence]: https://en.wikipedia.org/wiki/Subsequence
[listtoggle]: https://github.com/Valloric/ListToggle

View File

@ -1236,9 +1236,8 @@ documentation [50]. In short:
- If using GNU make, check out Bear [52].
- For other build systems, check out '.ycm_extra_conf.py' below.
If no '.ycm_extra_conf.py' is found, and no 'ycm_global_ycm_extra_conf' is
configured, YouCompleteMe automatically tries to load a compilation database if
one is found.
If no '.ycm_extra_conf.py' is found, YouCompleteMe automatically tries to load
a compilation database if there is one.
YCM looks for a file named 'compile_commands.json' in the directory of the
opened file or in any directory above it in the hierarchy (recursively); when
@ -1269,7 +1268,7 @@ Option 2: Provide the flags manually ~
If you don't have a compilation database, or aren't able to generate one, you
have to tell YouCompleteMe how to compile your code some other way.
Every c-family project is different. It is not possible for YCM to guess what
Every C-family project is different. It is not possible for YCM to guess what
compiler flags to supply for your project. Fortunately, YCM provides a
mechanism for you to generate the flags for a particular file with _arbitrary
complexity_. This is achieved by requiring you to provide a Python module which
@ -1278,13 +1277,15 @@ list of compiler flags to use to compile that file.
YCM looks for a '.ycm_extra_conf.py' file in the directory of the opened file
or in any directory above it in the hierarchy (recursively); when the file is
found, it is loaded (only once!) as a Python module. YCM calls a 'FlagsForFile'
found, it is loaded (only once!) as a Python module. YCM calls a 'Settings'
method in that module which should provide it with the information necessary to
compile the current file. You can also provide a path to a global
'.ycm_extra_conf.py' file, which will be used as a fallback. To prevent the
execution of malicious code from a file you didn't write YCM will ask you once
per '.ycm_extra_conf.py' if it is safe to load. This can be disabled and you
can white-/blacklist files. See the _Options_ section for more details.
compile the current file. You can also provide a path to a global configuration
file with the |g:ycm_global_ycm_extra_conf| option, which will be used as a
fallback. To prevent the execution of malicious code from a file you didn't
write YCM will ask you once per '.ycm_extra_conf.py' if it is safe to load.
This can be disabled and you can white-/blacklist files. See the
|g:ycm_confirm_extra_conf| and |g:ycm_extra_conf_globlist| options
respectively.
This system was designed this way so that the user can perform any arbitrary
sequence of operations to produce a list of compilation flags YCM should hand
@ -1295,23 +1296,23 @@ This is so that the correct language is detected, particularly for header
files. Common values are '-x c' for C, '-x c++' for C++, '-x objc' for
Objective-C, and '-x cuda' for CUDA.
To give you an impression, if your c++ project is trivial, and your usual
To give you an impression, if your C++ project is trivial, and your usual
compilation command is: 'g++ -Wall -Wextra -Werror -o FILE.o FILE.cc', then the
following '.ycm_extra_conf.py' is enough to get semantic analysis from
YouCompleteMe:
>
def FlagsForFile( filename, **kwargs ):
def Settings( **kwargs ):
return {
'flags': [ '-x', 'c++', '-Wall', '-Wextra', '-Werror' ],
}
<
As you can see from the trivial example, YCM calls the 'FlagsForFile' method,
passing it the file name. The '**kwargs' is for advanced users and can usually
be ignored. The 'FlagsForFile' function returns a dictionary with a single
element "'flags'". This element is a 'list' of compiler flags to pass to
libclang for the file 'filename'. That's it! This is actually enough for most
projects, but for complex projects it is not uncommon to integrate directly
with an existing build system using the full power of the Python language.
As you can see from the trivial example, YCM calls the 'Settings' method which
returns a dictionary with a single element "'flags'". This element is a 'list'
of compiler flags to pass to libclang for the current file. The absolute path
of that file is accessible under the 'filename' key of the 'kwargs' dictionary.
That's it! This is actually enough for most projects, but for complex projects
it is not uncommon to integrate directly with an existing build system using
the full power of the Python language.
For a more elaborate example, see YCM's own '.ycm_extra_conf.py' [53]. You
should be able to use it _as a starting point_. **Don't** just copy/paste that
@ -2209,14 +2210,14 @@ Supported in filetypes: 'cs, go, java, javascript, python, rust, typescript'
-------------------------------------------------------------------------------
The *ClearCompilationFlagCache* subcommand
YCM caches the flags it gets from the 'FlagsForFile' function in your
'ycm_extra_conf.py' file unless you return them with the 'do_cache' parameter
YCM caches the flags it gets from the 'Settings' function in your
'.ycm_extra_conf.py' file unless you return them with the 'do_cache' parameter
set to 'False'. It also caches the flags extracted from the compilation
database. The cache is in memory and is never invalidated (unless you restart
the server with the |:YcmRestartServer| command).
This command clears that cache entirely. YCM will then re-query your
'FlagsForFile' function or your compilation database as needed in the future.
This command clears that cache entirely. YCM will then re-query your 'Settings'
function or your compilation database as needed in the future.
Supported in filetypes: 'c, cpp, objc, objcpp, cuda'
@ -2740,25 +2741,25 @@ Default: '0'
The *g:ycm_extra_conf_vim_data* option
If you're using semantic completion for C-family files, this option might come
handy; it's a way of sending data from Vim to your 'FlagsForFile' function in
your '.ycm_extra_conf.py' file.
handy; it's a way of sending data from Vim to your 'Settings' function in your
'.ycm_extra_conf.py' file.
This option is supposed to be a list of VimScript expression strings that are
evaluated for every request to the ycmd server [49] and then passed to your
'FlagsForFile' function as a 'client_data' keyword argument.
'Settings' function as a 'client_data' keyword argument.
For instance, if you set this option to "['v:version']", your 'FlagsForFile'
For instance, if you set this option to "['v:version']", your 'Settings'
function will be called like this:
>
# The '704' value is of course contingent on Vim 7.4; in 7.3 it would be '703'
FlagsForFile(filename, client_data = {'v:version': 704})
# The '801' value is of course contingent on Vim 8.1; in 8.0 it would be '800'
Settings( ..., client_data = { 'v:version': 801 } )
<
So the 'client_data' parameter is a dictionary mapping Vim expression strings
to their values at the time of the request.
The correct way to define parameters for your 'FlagsForFile' function:
The correct way to define parameters for your 'Settings' function:
>
def FlagsForFile(filename, **kwargs):
def Settings( **kwargs ):
<
You can then get to 'client_data' with "kwargs['client_data']".
@ -3596,7 +3597,7 @@ continue reading.
The workaround is to call 'echo | clang -v -E -x c++ -' and look at the paths
under the '#include <...> search starts here:' heading. You should 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 your
list of flags you return from your 'Settings' function in your
'.ycm_extra_conf.py' file.
See issue #303 [81] for details.
@ -3793,7 +3794,7 @@ References ~
[50] http://clang.llvm.org/docs/JSONCompilationDatabase.html
[51] https://ninja-build.org/manual.html
[52] https://github.com/rizsotto/Bear
[53] https://raw.githubusercontent.com/Valloric/ycmd/3ad0300e94edc13799e8bf7b831de8b57153c5aa/cpp/ycm/.ycm_extra_conf.py
[53] https://raw.githubusercontent.com/Valloric/ycmd/66030cd94299114ae316796f3cad181cac8a007c/.ycm_extra_conf.py
[54] https://github.com/rdnetto/YCM-Generator
[55] https://help.eclipse.org/oxygen/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fproject_description_file.html
[56] https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html