Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324262

Summary: Open Declaration (F3) inconsistent behavior + Open Definition (Ctrl-F3) not working at all
Product: [Tools] CDT Reporter: Artem Russakovskii <archon810>
Component: cdt-source-navAssignee: Project Inbox <cdt-source-nav-inbox>
Status: RESOLVED FIXED QA Contact: Markus Schorn <mschorn.eclipse>
Severity: normal    
Priority: P3 CC: archon810, jvos, yevshif
Version: 7.0   
Target Milestone: 8.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
removes the (unimplemented) open definition command mschorn.eclipse: iplog-

Description Artem Russakovskii CLA 2010-09-01 21:36:14 EDT 
Build Identifier: 201006141710

This has been a gripe of an otherwise amazingly useful feature for years. Now with 3.6, it's still here.

Some of the time, pressing F3 on the function name will jump to its definition in the .C file. Pressing F3 again will start alternating between the .h declaration and the .C definition, which is perfect, and is exactly what I want.

Now, this behavior is very inconsistent. In a lot of cases, it will only jump to the .h file and subsequent F3s will not do anything, even though the definition is wide open in the .C. Sure - F3 is Open DECLARATION, fair enough - then why does it jump to the definition some of the time (see above)? Furthermore, there's an actual Open Definition (Ctrl-F3) which is only visible from Preferences->Keys and doesn't actually do anything.

Reproducible: Always

Steps to Reproduce:
See details.
Comment 1 Artem Russakovskii CLA 2010-09-01 21:37:08 EDT 
My version is actually 7.0.0.201006141710.
Comment 2 Markus Schorn CLA 2010-09-02 03:01:38 EDT 
(In reply to comment #0)
> ...
> Some of the time, pressing F3 on the function name will jump to its definition
> in the .C file. Pressing F3 again will start alternating between the .h
> declaration and the .C definition, which is perfect, and is exactly what I
> want.
That is the intended behavior.

> Now, this behavior is very inconsistent. In a lot of cases, it will only jump
> to the .h file and subsequent F3s will not do anything, even though the
> definition is wide open in the .C. 
> ....
Please provide instructions on how to reproduce such a problem. For example you can create a minimal project that shows the issue and attach it.

> ...
> Furthermore, there's an actual Open Definition (Ctrl-F3) which is only visible
> from Preferences->Keys and doesn't actually do anything.
The command should not be there, I'll remove it (see bug 167162).
Comment 3 Markus Schorn CLA 2010-09-02 03:06:56 EDT 
Created attachment 178020 [details]
removes the (unimplemented) open definition command

Removed 'Open Definition' command in 8.0 > 20100902.
Comment 4 Artem Russakovskii CLA 2010-09-02 03:12:19 EDT 
The problem is present in our quite complicated project. I'm not sure I'll be able to easily reproduce this but I can try when I get time.

I know it's hard to go on without knowing where exactly the problem lies but I'm not sure I'll be able to come up with an isolated test case. Please go off the assumption for now that you will not get a test case.
Comment 6 Jan de Vos CLA 2010-09-09 07:17:32 EDT 
I also see this problem in my project. This is also a pretty large project, and I am not really at liberty to share the entire source code, but I'll try to put together a small test project later. In the mean time, perhaps the following helps. In a .h file in my project, I have:

   FTC_t DoGetInterface(const char_t* pInterfaceName, void** ppInterface);
   void foo(char* bla);

Both methods are defined in the corresponding .cpp file (in the same directory). The FTC_t type is typedef'ed elsewhere (in a separate .h file, living in another directory in the same project).

For 'foo', the F3 behaviour is fine; for DoGetInterface it is not (F3 gets me the declaration, but not the definition).

When I change 'foo' to return an FTC_t (both in the .h file and the .cpp file), the F3 behavior no longer works -- I still get to the declaration from anywhere in the source code, but not to the definition.
Comment 7 Artem Russakovskii CLA 2010-09-09 15:04:21 EDT 
I think I tracked mine down to the same thing.

For example, HttpResultPtr HttpsConnection::Post()
where HttpResultPtr is defined in the .h of the same file as
typedef boost::shared_ptr<HttpResult> HttpResultPtr;

If I change HttpResultPtr to HttpResult* just to test, Open Declaration works just fine.

Additionally, we use the following MACRO instead of typedef at times, which is also not parsed correctly, for the same reason:
DECLARE_BOOST_TYPES(GdTag);

Here's the definition:
#define DECLARE_BOOST_TYPES(classname) \
class classname; \
typedef boost::shared_ptr<classname> classname ## Ptr; \
typedef std::vector<classname ## Ptr> classname ## PtrVec; \
typedef std::map<ub4, classname ## Ptr> Ub4To ## classname ## PtrMap; \
typedef std::multimap<ub4, classname ## Ptr> Ub4To ## classname ## PtrMultiMap; \
typedef std::map<ub8, classname ## Ptr> Ub8To ## classname ## PtrMap; \
typedef std::multimap<ub8, classname ## Ptr> Ub8To ## classname ## PtrMultiMap; \
etc ...
Comment 8 Markus Schorn CLA 2010-09-30 07:52:51 EDT 
I have removed the superfluous command in 8.0. Where the navigation to a definition does not work it is very likely that we have a problem parsing the code at that point. Please file bugs with specific examples for that.