Re: [cdt-dev] To be exact or to be close enough

[John Camelon <jcamelon@xxxxxxxxxx>]

Thanks Thomas for the input, my comments are inline. 

Cheers
JohnC
www.eclipse.org/cdt

Thomas the Noble wrote:
<snip>
> As it stands today the user opens up the source in the editor, their 
> outline shows a fairly "complete" set of information but then when they 
> go to use features such as code completion (on my_function), open 
> declaration/open type on (on uint8_t) then what happens (failure) is
> not consistant with the outline indicating that this is a function.

FYI, there are many places where the Outline view is inconsistent with the 
indexer's view on code in the workspace.  The decision that we made was 
that we wanted an outline view to show up for all users, regardless of 
whether or not they have properly configured their include paths or not, 
thus the parse is only doing a syntactic match.  You'll notice that there 
are points where fields have the icons for variables, methods definitions 
have the icons for function definitions, etc.  These divergent views need 
to be unified at some point, most likely post-2.0 in order to allow for 
full compliance w/Eclipse UI guidelines. 

> This can happen for a lot of different reasons, mostly going back to
> "incomplete" configurations (defines and/or include paths not set). 
John,
> Bogdan, Vlad, Sean and others are working hard to make sure that the
> user knows about these problems and can fix them  However, here are some 

> things I'm wondering about: 

> - What happens when the error is in source you don't control (ie OS 
header
> files)
> - Why should we have to re-index everytime a define or include path 
changes?
> 
> The first concern is just a practical issue.  Even with scanner/parser
> extensions
> coming along in 2.0, there may be compiler specific issues that are
> encountered
> and for the user, they may or may not care/be savy enough to be able to 
fix
> it.
> What happens then?  Are they stuck?

Depends what you mean by 'stuck'.  C/C++ Parser support in CDT 2.0 shall 
be limited to, for the most part, the syntax and semantics supported by 
the latest version of GCC, with emphasis being placed on supporting 
standard libraries and other well-known libraries and projects.  We 
recognize that we will not be able to get the complete solution for GCC, 
given that some extensions have come and gone over the past 10 releases. 
With that in mind, I have been adding in full IProblem support into the 
parser so that problems that the parser recognizes are reported to the 
client.  This IProblem support shall be used by the Indexer to support the 
concept of an 'inexact' match.  We shall do our best to improve the error 
handling so that we make as much progress as we can, but not at the 
expense of laxing our focus on finding exact matches. 

Inexact match support, along with the work Vlad is doing, should get us 
over the hump for CDT 2.0.  There will always, unfortunately, be build 
environments and makefiles that will fail the standard make usability 
feature, and thus can potentially move users into the 'stuck' state. 
Similarly, using a non-supported version of GCC or even another compiler 
could break the error handling in particular cases that may again 'stick' 
a user.  The goal of CDT 2.0, however, is that w/proper 
IScannerInfoProvider implementations, and GCC, there should be very few 
'stucks'. 

> The second concern comes up in my mind again and again.  Should we be
> indexing
> _everything_ and where ambiguous flag something as uncertain rather than
> only
> indexing the things we are absolutely sure about?  I realize that this 
is 1)
> a significant challenge 2) closer to full text indexing which is already
> provided
> by Eclipse 3) a problem we can solve many different ways.  I also get
> concerned
> if we start thinking about having "scanner configurations" (ie windows, 
QNX,
> VxWorks,
> Linux, Cygwin etc) and how the user might flip between configurations
> regularily
> and on large projects the time spent scanning and indexing is going to 
be
> nuts.

The 'multiple scanner configuration' aspect of the problem is extremely 
difficult to solve without a unified view of what a configuration is 
between the different builders and a concept of tools and targets.  If you 
are looking for a way to help, then I would suggest driving the 
Target/Toolchain discussions to completion. 

I would not have a problem for having multiple indices for different 
configurations _if_and_only_if_ we were able to reduce the indexer 
scalability issue to purely that use-case (flipping between configs).  We 
all know that is currently not the only issue with indexer and parser 
scalability on huge workspaces. 


> Before I spend too much time really looking at these problems/issues I
> thought
> I would get peoples feedback (ie "Oh yeah ... I'm already planning on
> looking 
> at that but here is where you could help" =;-)