Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Questions on CDT's indexer/parser internals



On Thu, Aug 16, 2012 at 2:30 PM, Erica Mealy <ericamealy@xxxxxxxxx> wrote:
Thank you Sergey!

One last question, is there anything in the bugs (that I've missed) or
on the radar about parsing/indexing code that does not compile with
gcc/g++? We have projects that our other tool supports (a tool we're
looking at creating a plugin for) that use the C/C++ compilers from
Intel, Solaris and MS Visual Studio. Ideally, once we build our
plugin, we'd like to support all these from Eclipse as well.

CDT parser supports some language extensions for non-gcc compilers, for example __declspec. Nothing prevents us from adding more such extensions.

For building, I believe that you can set the external build command,
so if those compilers exist, using them for the build/link should be
possible. However, the parser/indexer uses an internal, hand-rolled
gnu like parser doesn't it?

Yes, CDT uses its own parser and AST format optimized for IDE needs.

Would the community see value in the ability to use other C/C++ compilers?

Our thoughts are long the line of using an external compiler framework
and pulling it's IR/AST back into CDT's format. Ideally only  passing
out deltas for parse/index when necessary.

Conversion between different AST formats is problematic, particularly because some compilers don't preserve all information that CDT needs. Implementing AST API in JNI would require a lot of effort.

Looking forward to hearing other's thoughts,

Erica.

-sergey 

On Mon, Aug 13, 2012 at 9:50 AM, Sergey Prigogin
<eclipse.sprigogin@xxxxxxxxx> wrote:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=299911 has been fixed few days
> ago together with https://bugs.eclipse.org/bugs/show_bug.cgi?id=374993. For
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=381601 we need to better
> understand the problem before attempting to fix it. There are no current
> plans to work on https://bugs.eclipse.org/bugs/show_bug.cgi?id=315964.
>
> -sergey
>
>
> On Sun, Aug 12, 2012 at 3:44 PM, Erica Mealy <ericamealy@xxxxxxxxx> wrote:
>>
>> Thanks Nathan.
>>
>> That's really helpful. Does anyone know the plans for/status of the
>> bugs that have been raised that Nathan has mentioned?
>>
>> Regards,
>>
>> Erica.
>>
>> On Wed, Aug 8, 2012 at 5:18 PM, Nathan Ridge <zeratul976@xxxxxxxxxxx>
>> wrote:
>> >
>> >> The Issues we're talking about are ones that are already documented
>> >> for other larger projects like Mozilla
>> >> (https://developer.mozilla.org/en-US/docs/Eclipse_CDT#Known_Issues).
>> >>
>> >> What we really what to know is what's happening going forward on the
>> >> indexer.
>> >> Is it as bad as the original CDT documentation said or has it had
>> >> enough recent work to be mostly in shape.
>> >>
>> >> If someone who knows more about the indexer's recent history could
>> >> catch us we we'd really appreciate it. And I don't mind taking the
>> >> conversation offline so everyone doesn't get spammed on it. :-)
>> >
>> > I'm not a CDT developer, but I can share my experience as a CDT user.
>> >
>> > I have been using CDT since Ganymede (which was released in 2008).
>> > Initially the imperfections in the parser/indexer were very
>> > noticeable (red underlines weren't introduced until Indigo, but the
>> > imperfections were apparent in the incorrect syntax highlighting and
>> > code navigation). I have filed over 50 bugs in the parser/indexer
>> > since then, most of which have been fixed. I think that overall the
>> > CDT parser/indexer has come a long way since Ganymede. There are
>> > still false positive errors, but their frequency is much lower than
>> > before.
>> >
>> > The following bugs have been/are responsible for the greatest number
>> > of false positive errors in our codebase:
>> >
>> >
>> > 1. https://bugs.eclipse.org/bugs/show_bug.cgi?id=197989
>> >
>> > This bug relates to storing multiple variants of a header file in
>> > the index. In the presence of #ifdef/#endif blocks, the parts of
>> > a header file that are seen by the compiler can depend on what
>> > macros are defined (and what values they have) when the header
>> > file is included (the "macro dictionary"). Often the same header
>> > file can be included in two different places with different
>> > macro dictionaries. If only one of the variants is stored in the
>> > index, then code that relies on declarations present only in the
>> > other variants is not indexed accurately.
>> >
>> > This bug is fixed in Juno, but the fix is only partial. Multiple
>> > variants are only stored for header files which have no include
>> > guards, and which are therefore meant to be included multiple
>> > times *in the same translation unit*. This issue, however, can
>> > also affect header files which have include guards, if different
>> > variants of them are included in different translation units.
>> > Storing multiple variants of all header files, however, leads to
>> > a combinatorial explosion of variants, which is why it wasn't
>> > implemented.
>> >
>> > Proposals to mitigate this remaining problem can be found here:
>> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=381601
>> > and here:
>> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=380511
>> >
>> >
>> > 2. https://bugs.eclipse.org/bugs/show_bug.cgi?id=299911
>> >
>> > This bug relates to parsing "dependent expressions", which are
>> > expressions of the form 'sizeof(e)' (or, in C++11,
>> > 'decltype(e)') that appear in a template and where e is
>> > dependent on some of the template parameters. CDT cannot store
>> > these correctly in the index, leading to problems when they
>> > are used in a header file.
>> >
>> > Code that uses the Boost libraries is particularly suspectible
>> > to this bug because Boost type traits metafunctions such as
>> > boost::is_convertible<T, U>, which are used throughout Boost,
>> > use dependent expressions of the form 'sizeof(e)'.
>> >
>> > This bug is not yet fixed, though a recent comment indicates
>> > that most of the work has been done and outlines the remaining
>> > steps. This bug causes the great majority of the remaining
>> > false positive errors in our codebase, which uses Boost
>> > extensively.
>> >
>> >
>> > 3. https://bugs.eclipse.org/bugs/show_bug.cgi?id=315964
>> >
>> > This bug relates to header files which are meant to be included
>> > at a non-global scope. CDT cannot parse these at all, because
>> > it expects that all header files contain declarations in the
>> > global scope.
>> >
>> > Admittedly, header files are seldom used like this, but some
>> > projects use them to e.g. generate members of an enumeration
>> > using an external tool, and then include the generated file
>> > like so:
>> >
>> > enum E
>> > {
>> >    #include "members.autogenerated.h"
>> > };
>> >
>> > An approach for fixing this bug has been outlined in a comment
>> > to the bug, but no one has implemented it yet.
>> >
>> >
>> > I believe that once these 3 issues are fixed, there will be
>> > very few false positive errors given by CDT (at least in our
>> > codebase).
>> >
>> > Regards,
>> > Nate
>> >
>> > _______________________________________________
>> > cdt-dev mailing list
>> > cdt-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top