Community
Participate
Working Groups
If the definition and/or implementation of a class is done completely with a macro, the C++ browser cannot show the members of that class.
Please provide an example to demonstrate the behaviour. Does this problem exist in the Outline as well?
Created attachment 11731 [details] source file in question Here is the source file that is offending, Chris. The outline handles it properly, but when you try to browse in the class browser to the class InvalidParameter, it craps out.
It looks like the indexer does not report anything. You will have also nothing if you start the Indexer. The class browsing and the Open Type now rely completely on the indexer to provide the information.
What I am seeing: the class InvalidParameter shows up in the TypesView but the MembersView is empty. Is this what you mean by "craps out"? There appears to be a problem with the parser reporting incorrect offsets when expanding the macros. The browser attempts to locate the ICElement for the class InvalidParameter by calling TranslationUnit.getElementAtOffset(). What happens here is the offset of the class and all of its children are the same so the wrong element is found. Can you take a look at this, John?
Those offsets are correct, they are what is necessary for the outline view. TranslationUnit.getElementAtOffset() should really be TranslationUnit.getElementsAtOffset() (an array) due to macro expansions. CC-ing Alain for his opinion and assigning to the inbox.
Alain would love to do this. :)
> Alain would love to do this. :) Done, let me know if it works for you.
Fixed.
Created attachment 12946 [details] test project Zip file contains project with reproduceable case.
Reopening to track problems showing up in Joost's test project. The file Exception.cpp does not display properly in the outline view. Looks like it's not getting parsed correctly.
If I comment out the "#include <windows.h>" in Exception.cpp the class declaration shows up correctly in the outline view. It appears to just fail silently - there's nothing being written to the error log. John, can you take at look at this?
I'm also seeing a lot of flickering in the outline view when I make a change. Looks like it's redrawing 4 or 5 times. (This is on Win2K).
The class forward declaration for ExceptionText in Exception.hpp also causing a problem. The type cache is relying on this symbol from the indexer instead of the actual declaration (and hence the correct location). See bug# 59493.
I've seen the flickering too ... some one on the newsgroup also commented upon it. Perhaps Hoda can take a look @ it this week ...
Chris, Are you recommending to people to use the "follow #include's" mode on the Outliner in order to get the browsing view working properly? I don't think that's a good idea.
The "follow #includes" thing is just a workaround for the time being. I'm hoping that with your new and improved parser, we can do a full parse every time so this won't be an issue - is that a reasonable assumption?
Definitely not for 2.0.1. Most likely not for 2.1 unless we can figure out some sort of caching strategy. It is not a workable solution to parse #include files on reconcile.
The flickering bug has been fixed in Head and branch.
Even if we get parse times down to a second on a seriously complex file, I don't think we can use STRUCTURAL_PARSE on reconcile.
Original bug has been verified fixed (getElementsAtOffset() and indexer class forward bug# 59493). The only outstanding issue is bug# 71736 (ie follow #includes must be turned on or the C++ class with macros may not display correctly) but this affects the whole CModel so I think we can deal with this elsewhere (or create a separate PR). Should already be fixed in head and 2.0.1. Can someone please mark this one fixed - I guess my new committer powers don't extend to bugzilla...
Your committer powers should extend to bugzilla! Perhaps Doug or Kleo can send an email on your behalf to the powers that be.
