Java language support
David Nolden
zwabel at googlemail.com
Tue Nov 24 08:53:54 UTC 2009
Am Dienstag 24 November 2009 09:14:34 schrieb Hamish Rodda:
> Hi David,
>
> On Fri, 31 Jul 2009 12:27:19 am Hamish Rodda wrote:
> > On Thu, 30 Jul 2009 03:56:15 pm David Nolden wrote:
> > > Am Donnerstag 30 Juli 2009 05:37:23 schrieb Hamish Rodda:
> > > > The current plan was to create and execute new parse jobs in a
> > > > recursive fashion as needed in void ParseJob::run(), probably in the
> > > > if (builder.identifiersRemainUnresolved()) { bracket.
> > >
> > > I think that plan is not ideal. As many languages have this problem,
> > > for example also php, we should solve it once and for all, by looking
> > > how those languages themselves do it, and replicate that behavior.
> > >
> > > My initial guess: Use 3 passes over the complete project.
> > > Pass 1: Only put declarations into the symbol table
> > > Pass 2: Build types (requires full declaration info)
> > > Pass 3: Build uses (requires full type info)
> > >
> > > Pass 2 and 3 can probably be merged in some way, as one could also
> > > build type- uses while resolving the types in pass 2, and thereby have
> > > a kind of inheritance chain. Anyway that should be secondary, primary
> > > goal should be first getting it working properly.
> >
> > Sure, that would be a good plan too. Can the background parser figure
> > out when a job didn't complete the required parsing flags, and reschedule
> > the url for parsing again?
>
> What would be the best way to implement your proposal? (If you've answered
> earlier, sorry, but I can't find the response now).
>
> Cheers,
> Hamish.
>
> PS. for those who were curious, while I was absent from programming I got
> married... here are some shots from a passer by:
> http://www.flickr.com/photos/86912114@N00/sets/72157622231831171/show/
Congratulations for your marriage. :-)
About the multi-pass parsing: Actually I have added some of the required
infrastructure within the last days, although it isn't quite perfectly tested
yet.
Generally, you could do the following:
- Process the whole project using the
TopDUContext::SimplifiedVisibleDeclarationsAndContexts feature-flag. In that
mode, the language-support should just create declarations and 'local' types
(Assign type "Class" to declaration "Class"), but should not resolve any
types.
- Once all files have been processed, process them again using the
VisibleDeclarationsAndContexts or a higher feature-flag.
Actually it might also be enough in java to completely leave out the second
step, as the file will be queued automatically with a higher feature-set once
it's opened in an editor.
Greetings, David
More information about the KDevelop-devel
mailing list