This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 185813 - Unable to resolve identifier in std::complex specializations
Summary: Unable to resolve identifier in std::complex specializations
Status: RESOLVED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: Code Model (show other bugs)
Version: 6.x
Hardware: PC Linux
: P2 normal (vote)
Assignee: Vladimir Voskresensky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-09 21:54 UTC by bb125
Modified: 2010-05-12 16:15 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
testcase (450 bytes, text/plain)
2010-05-12 09:16 UTC, Egor Ushakov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bb125 2010-05-09 21:54:51 UTC
Unable to resolve identifier in std::complex specializations

The following simple compilable example produces "Unable to resolve identifier" at the marked function call:

// main.cc
#include <complex>
#include <iostream>

std::complex<double> foo2()
{
  return std::complex<double>(1.0, 0.0);
}

int main(int argc, char** argv)
{
  std::cout << foo2().real() << "\n";
  //                  ^-- Unable to resolve identifier real
  return 0;
}


I found this behavior for NB6.8 and also for NB6.9beta on Linux (Suse 11.2 64bit).


Side notes:

* NB6.8 and NB6.9beta: Navigation to the erroneously unresolved function fails (Ctrl-click on the function name real has no effect).

* NB6.9beta only: If I go to the complex header file (Ctrl-click on the filename in the include line) I find a quite big number of red marks (unexpected tokens, unresolved identifiers, etc...) To me it looks like NB failes to parse the header file <complex>.
  
* NB6.9beta only: After playing around with other sources and then eventually going back to the given sample, I found that reparsing the project (Code assistance → reparse project) changes the shown error marks:
  - Sometimes even the identifier 'complex' cannot be resolved.
  - Sometimes the include line is marked with a yellow ! saying that there are unresoveld includes inside.
  - Somtimes all red marks disappear, but unfortunately the identifiers remain unresolved (Ctrl-click on the indentifies still has no effect).
Comment 1 soldatov 2010-05-10 08:39:57 UTC
(In reply to comment #0)
> Unable to resolve identifier in std::complex specializations
> 
It is http://netbeans.org/bugzilla/show_bug.cgi?id=184779
Comment 2 Vladimir Voskresensky 2010-05-10 22:54:12 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Unable to resolve identifier in std::complex specializations
> > 
> It is http://netbeans.org/bugzilla/show_bug.cgi?id=184779

Thanks. I will close as duplication.

All other "unstable" behavior should be fixed in current dev builds, i.e. issue 185009

*** This bug has been marked as a duplicate of bug 184779 ***
Comment 3 Egor Ushakov 2010-05-11 15:45:30 UTC
The problem here is not that __real__ and __imag__ are unresolved, this was in gcc 3 as well and real was NOT unresolved.
In gcc 4 they have changed complex from class to struct.
I played with that and it seems that specialization has some issues with that.
Comment 4 Egor Ushakov 2010-05-11 16:11:50 UTC
actual problem is that in version 4 they've changed complex class to struct but have left forward declarations as class:

// Forward declarations.
  template<typename _Tp> class complex;
  template<> class complex<double>;

...
template<typename _Tp>
    struct complex
    {
...
}
we need to hack code model to work with this.
Comment 5 Leonid Lenyashin 2010-05-11 16:19:42 UTC
Isn't it an incorrect, non-standard usage of language? If it is so I'm not convinced we need to hack our code model to comply.
Comment 6 Egor Ushakov 2010-05-12 09:16:38 UTC
Created attachment 98825 [details]
testcase

In this testcase mycomplex<float> has foo in codecompletion and mycomplex<double> (double specialization) does not.
Comment 7 Vladimir Voskresensky 2010-05-12 09:52:38 UTC
thanks for the test case. I will investigate
Comment 8 Vladimir Voskresensky 2010-05-12 16:15:44 UTC
fixed:
http://hg.netbeans.org/cnd-main/rev/efdc4f610c8a