Resource change listeners will only give
you updates on resources in the workspace though. Many parsed files will
be in system includes and user included directories.
I’m not saying don’t do it, I’m
just saying that it won’t cover every single situation. There is
only so much you can do about files that Eclipse doesn’t truly know about
in the resource sense. There would have to be some sort of periodic scan
for these files.
___________________________________________
Chris Recoskie
Texas Instruments, Toronto
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Robert O'Callahan
Sent: Tuesday, July 05, 2005 12:38
AM
To: CDT General developers list.
Subject: Re: [cdt-dev] completion
performance
On 05/07/05, John Camelon
<jcamelon@xxxxxxxxxx> wrote:
I've given some thought on how incremental parse can
work.
When
one edits a working copy, we can use the change bars to determine what portion
of the parse tree is dirty or not.
Content
Assist (or the selection features as well) hold onto the AST between parses and
we use the clean-up-until-offset to determine how to prune the tree and where
to restart.
Of
course, we would have to add in a bunch of eventing to make sure that we would
be getting up to date working copies and/or saved files as time went on.
It seems fairly simple to use a resource change listener to detect changes to
included files referenced by cached parser(s), and use the change bars to
detect changes to the current file/translation unit. I'm assuming that it's
correct to do the parse using the working copy of the current file and the base
copies of all included files.
That being said, the largest problem with having a
feature hang onto an AST is that the footprint is quite substantial. The
only thing we have been able to cache up to this point are the decoded file
buffers as CodeReaders. The syntactic AST has fine granularity, which
means that to some extent, the number of nodes in the tree are preportional to
the number of tokens in the translation unit. Sharing AST-fragments
between parses (i.e. the physical AST for windows.h) is difficult since the
content of a file depends upon the IScannerInfo (which may change, w/per file
options or discovery) or even the order of include directives.
In the first step I wouldn't worry about this :-). A simple approach would just
keep one cached parser in a given workspace.
Sharing AST fragments might not be hard because you don't have to predict in
advance whether an AST fragment will be shareable (the problem is a bit
different from precompiled headers). You can parse a few translation units,
compare their AST structure, and share subtrees that you know are identical.
However you won't be able to share AST fragments that have bindings, you'll
definitely have to clear and recompute bindings whenever you change the context
in which you're using a shared AST fragment.
Rob
--
["Therefore, my dear friends, as you have always obeyed–not only in
my
presence, but now much more in my absence–continue to work out your
salvation with fear and trembling, for it is God who works in you to will
and to act according to his good purpose." Philippians 2:12-13.]
|
