consider this simple code:
#include <vector>
#include <string>
using namespace std;
vector<string> vec1;
//vec1. //completion does not work AND break the completion that used to work if left without semicolon.
int main(){
vector<string> vec2;
vec2.push_back("sometext"); //completion works
vec1.push_back("sometext"); //works here too
return 0;
}
When I type "vec2." or "vec1." I am presented with a drop down list of all methods of the string type right after I type the point. So it works here.
Here is how it gets strange:
1) When I do "vec1." in the global scope right before main I am presented with wrong options in the drop down menu (namespace, using, asm, typedef, using, static_assert, extern, etc...). And it cannot find 'push_back' at all ("User defined completion (^U^P^N) Pattern not found)
2) Now, If I leave this line unfinished and forget to put a semicolon I then can't have proper autocompletion inside main() as I did before!
Only plugins I have running are clang_complete and supertab. I tried without supertab and with various _vimrc and .clang_complete settings to no benefit. I'm on win7, llvm/libclang are from official website.
Is it normal that it bugs like that?
The plugin relies completely on libclang to do the completion, which in turn only completes code that's more or less valid (I think it can forgive some errors before the cursor from which the parser is able to recover and code after the cursor can contain more serious errors).
Statements at the global scope are not among valid syntactical constructs of C++. This probably confuses clang's parsing enough to make it return some generic completion list that's not tied to the immediate context.
I think such behaviour is expected for any completion system that employs clang, unless it's explicitly worked around in some way.
Related
The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
But then, there comes the error: (Make:47 missing endif. Stop).
If I comment out those three lines of code, the error becomes: (<math.h> no such file or directory).
My system is OpenSUSE Leap 15.4; gcc version 7; gnu make version 4.2.1-7.3.2.
I think I have installed all the needed packages. However the errors persist. Any help?
I primarily want to address this part of the question, as the underlying issue has been addressed elsewhere, multiple times:
The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
I started to write "Google led you astray", but I think it's more likely that you seriously misunderstood what it led you to. And perhaps you happened to choose poor results.
The error message indicates that you put those lines in your makefile, but they are wholly inappropriate for that. Don't put them there.
The lines are C preprocessor directives that have been stripped of their leading # characters. You would use them by restoring the # characters ...
#ifdef __linux__
#define _finite(v) (__builtin_isfinite(v))
#endif
... and putting the resulting lines into one or more of your C source files. BUT DON'T! Those lines are unnecessary and at best unhelpful.
You do need to #include <math.h> in each C source file that contains a call to isfinite(), because that is the header that provides a declaration of the function. Since C99, functions must be declared before they are called (and it was good practice well before then).
Other than that, with GCC and many other traditional-style Unix C compilers, you need to explicitly include the math library in your link when you need any of the functions it provides. That would involve adding -lm to your makefile, at the end of the gcc command that builds the final executable. This is covered in gcc will not properly include math.h, and many other duplicates on this site.
I'm not really sure why "cout" and "endl" are not being recognized. Any help would be great!
The error is:
and the code is:
The fact that iostream has a red squiggle underneath it is a near certainty that you have something wrong with your environment (such as compiling with a C compiler rather than a C++ one, for example).
You need to fix that, since cout and endl are defined in that header. I'd start by hovering the mouse over the iostream text and see what the tooltip shows you.
If it cannot find the file iostream then you're either not using a C++ compiler, or your environment is severely damaged.
Either way, it's not a correct C++ environment.
Things to look in to are (to start with):
Examine the file extension. Using *.c instead of *.cpp may use a C compiler rather than a C++ one, for example).
Examine the output of your compilation, if available. You will hopefully be able to tell which compiler is being used.
If you are sure you're using a C++ compiler:
You might have a funny character in your iostream string. You could totally delete that line and retype it (don't edit, it may not get rid of the funny character).
Try a different header (like cstdlib) to see if it has the same problem.
Last-straw solution would be re-installation of your development environment, in case things are so damaged it's unrecoverable.
I have a .h file who contains these code:
template<BLA>
func1() {}
// something
template<BLA>
func2() {
func1();
}
when I typed the command GoToDefinition, the error appeared :"YCM : 'RuntimeError : can't jump to definition.'".
Do I miss something? And how to find the definition?
By the way, I have this in my .vimrc:
let g:ycm_global_ycm_extra_conf = ' ~/ycm_extra_conf.py'
**************second edit*******************
I reinstalled my YCM, and I tried ctags for YCM by this command :
ctags -R --fields=+l
It works, and thanks.
Last time I've checked, YCM understanding of a source code is restricted to one translation unit. It'll be very difficult for it to find where a function is defined as it's likely to be in another translation unit.
In other words, it should work as long as you want to jump to a definition that is in the same .cpp file as the one your are currently editing.
Thus, it should also work when trying to access to a template function definition from it's call site -- as we're supposed to include the related code. If it doesn't, it could be related to an improper understanding of the source code by clang engine YCM is using, or to YCM not configured to use clang.
Regarding tags, they could do the job, but indeed, in C++, you'll want a way to narrow the tags presented. That's what had me started lh-tags: it presents all matching tags and it permits to filter them on various criteria (filename, kind, scope, ...)
Given the following code:
// MyClass.h
class A {
void foo();
}
class B {
void foo();
}
// MyClass.cpp
void main() {
A a();
a.foo();
}
Given that I am using vim and have my ctags generated, if I place my cursor over the foo() in main() and hit ctrl+], I will get a list of the implementations of foo, as there are more than one. If there was only one, then it would jump immediately to that implementation.
Is there a way in vim for the type of a to be inferenced such that when I hit ctrl+], it immediately jumps to the implementation of A::foo() rather than supplying me with a list of choices? It seems like such a plugin should exist and I am just unable to find it.
Update: It appears that there is currently no solution to this problem, so I have selected exclipy's answer below. Should a solution present itself and a new answer be made available, I will update the answer to this question.
What you want to do isn't possible unless Vim can actually parse the entire C++ translation unit, as a C++ compiler would. This is far beyond the scope of ctags, which uses very simple heuristics to merely tokenize the vicinity of the cursor.
So the obvious solution to this is... plug a C++ parser into Vim! There is actually a plugin called clang_complete, which already does most of the heavy lifting of hooking into the Clang C++ parser. From this base, it should be a simple matter to extend it to use the Clang API to implement jump-to-definition.
In fact, I have started working on such a feature, through two projects: clang_indexer, which crawls the source tree to build an index on disk, and my fork of clang_complete, which adds the feature of querying the index for usages of the symbol under the cursor. This is actually a bit more than what you're after because I'm aiming for a "find all references" feature (with the option of filtering the results to just definitions).
It's at a very early stage and I'm only doing it for myself, so don't expect it to be very polished solution.
is there a way i can print __FUNCTION__ as a wide character on linux?
the trick with the WIDEN doesn't work for me, the gcc compiler prints:
error: ?L_FUNCTION_? was not declared in this scope
any help?
Thanks
7+ years later (although things seem to be the same) ...
Since you mentioned gcc, check [GNU.GCC]: Standard Predefined Macros (emphasis is mine):
C99 introduced __func__, and GCC has provided __FUNCTION__ for a long time. Both of these are strings containing the name of the current function (there are slight semantic differences; see the GCC manual). Neither of them is a macro; the preprocessor does not know the name of the current function.
Since __FUNCTION__ is not a macro (the preprocessor doesn't "know" anything about it), it will remain untouched during (outer) macro expansion, generating at the end the L__FUNCTION__ identifier, which is obviously invalid. That's why the double macro approach works for __FILE__ (for example), but not for __FUNCTION__ (or __func__).
So, the short answer to your question is "NO" (at least not at preprocessor level). You will need to convert __FUNCTION__ "manually" (e.g. using one of the [man7]: MBSTOWCS(3) functions family).
Note: It works on VStudio, since according to [MS.Docs]: Predefined Macros (emphasis still mine):
__FUNCTION__ Defined as a string literal that contains the undecorated name of the enclosing function. The macro is defined only within a function.
It can be done using macros, you just have to understand how macros expand.
To get a wide char version of the macro you need to create 2 layers of macros like so:
#define WIDE2(x) L##x
#define WIDECHAR(x) WIDE2(x)
#define WIDE_FUNCTION WIDECHAR(__FUNCTION__)
The all important piece is the L##x that appends the L character to the string constant before the compiler sees it. You can do this to __FILE__ as well using the same technique.
That looks more like a typo of __FUNCTION__ than an issue with widen() or similar, at least if you pasted the exact error message.