-
Notifications
You must be signed in to change notification settings - Fork 363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
template parameter std::enable_if_t not parsed #2305
Comments
Hi @slnj, thx for your feedback, we will have a look. Could you provide also the error message you get please? Regards, |
Hi Günter, But I have sonar.cxx.errorRecoveryEnabled = true. Maybe I'm not understanding things correctly and these errors are expected when errorRecoveryEnabled=true |
Correction: Even with errorRecoveryEnabled=false, get error but changed to (this is a sample):
And only appears one error in each file, only on the fist template declaration |
Hi @slnj,
The difference is explained here:
The problem in your case seems to be the type traits. The cxx parser implements a C++ grammer and type traits are not part of it. But actually it doesn't matter, because the "correct syntax" is only needed for some cxx rules (https://github.com/SonarOpenCommunity/sonar-cxx/wiki/CXX-Rules) and the correct calculation of the software metrics. Reports from external tools can also be assigned correctly despite syntax errors. Until the error is fixed, you should normally be able to ignore the error message. Regards, |
Thanks Günter, Regards, |
Keep it open for further investigations. |
template < typename T , std::enable_if_t<std::is_base_of<BaseT, T>::value, int> = 0 > class A {}; // error
template < typename T , typename std::enable_if <std::is_base_of<BaseT, T>::value, int>::type = 0 > class A {}; // ok
|
Issue is in template < typename T , std::enable_if_t<std::is_base_of<BaseT, T>::value, int> = 0 > class A {}; // error
template < typename T , std::enable_if_t<std::is_base_of<BaseT, T>::value, int> > class A {}; // ok |
- supporting type traits helper as typeParameter (e.g. std::enable_if_t) - close SonarOpenCommunity#2305 ```C++ template <typename T, typename std::enable_if <std::is_base_of<BaseT, T>::value, int>::type = 0> class A {}; template <typename T, std::enable_if_t<std::is_base_of<BaseT, T>::value, int> = 0> class C {}; ```
Hi @slnj, there is a fix available: #2306 You can download and try with this version: Please give us feedback. Regards, |
Hi Günter,
I get an error on the constructor, but if instead I use It seems the |
The same happens with the operators:
is accepted but
is not |
Hello @slnj, is a bigger thing. All places where an implicit conversion to typename can take place must be checked. I'm not sure if we can do this adapting the grammar. The cxx plugin is verifying only the grammar (syntax check) without a semantic check. Regards, |
But this is not about enable_if_t.
|
Hi @slnj, The reduction makes the problem more transparent. It is a ambiguous grammar problem with class A {
template<typename T = 0 > A ( T num ) {}
}; Not sure if we can solve this because parser has no semantic knowledge. Maybe we can add some syntax sugar for most common cases?
Regards, |
cases I found in VC and Boost:
template <typename Collection, std::enable_if_t<std::is_convertible_v<Collection, interface_type>>* = nullptr>
template <class T> void _Cleanup(T* /*values*/, unsigned /*actual*/, typename enable_if<!__is_class(T) && !(is_pointer<T>::value)>::type = 0) {}
template <typename T, std::enable_if_t<is_implements_v<T>, int> = 0>
template<class T> void destroy(T*, typename std::enable_if<std::is_trivially_destructible<T>::value>::type* = 0) {}
template<class T, typename std::enable_if<!std::is_trivially_destructible<T>{} && (std::is_class<T>{} || std::is_union<T>{}), bool>::type = true> |
Hi @slnj, please try again, there is a new fix available. You can download and try with this version: Regards, |
Hi Günter, I tried with sslr toolkit and it seems this new version solves the problem!! And yes, I use I'm just making a full code check. I'll let you know the result. Regards |
Hi Günter, Thanks!!! |
Hi,
I have some parsing issues using version 2.0.6.
It seems the problem occurs when I use std::enable_if_t macro helper in templates
There is not problem using std::enable_if like:
But parsing fails if using similar but simplified syntax using std::enable_if_t :
Yo can see it usage at the "Notes" section at https://en.cppreference.com/w/cpp/types/enable_if
Both syntax have similar functionality, only that enable_if_t adds the "template" and ":type" on it definition (can see a type_traits header file), so both "template" and ":type" are not needed when used.
std::enable_if_t helper is specified since C++14 ( according to cppreference )
It's expected both alternatives to be recognized, but only the fist one is.
The text was updated successfully, but these errors were encountered: