Re: [cdt-dev] To be exact or to be close enough
Thanks Thomas for the input, my comments are inline.
Thomas the Noble wrote:
> 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).
> 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
> - Why should we have to re-index everytime a define or include path
> The first concern is just a practical issue. Even with scanner/parser
> coming along in 2.0, there may be compiler specific issues that are
> and for the user, they may or may not care/be savy enough to be able to
> 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
> The second concern comes up in my mind again and again. Should we be
> _everything_ and where ambiguous flag something as uncertain rather than
> indexing the things we are absolutely sure about? I realize that this
> a significant challenge 2) closer to full text indexing which is already
> by Eclipse 3) a problem we can solve many different ways. I also get
> if we start thinking about having "scanner configurations" (ie windows,
> Linux, Cygwin etc) and how the user might flip between configurations
> and on large projects the time spent scanning and indexing is going to
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
> I would get peoples feedback (ie "Oh yeah ... I'm already planning on
> at that but here is where you could help" =;-)