Java language support

David Nolden zwabel at googlemail.com
Tue Nov 24 11:09:47 UTC 2009


Am Dienstag 24 November 2009 11:37:27 schrieb Hamish Rodda:
> On Tue, 24 Nov 2009 07:53:54 pm David Nolden wrote:
> > 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. :-)
> 
> Thanks :)
> 
> > 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.
> 
> Because java won't have the same import structure (it currently uses a
>  global top context) the second step likely will be needed... any good way
>  to detect when the first step is completed?

Hmm there is 2 options that come into my mind: Either you adapt 
"ProjectParseJob" so it manages the whole thing, or you let each 
"JavaParseJob" enqueue a follow-up parse-job with a worse priority into the 
background-parser if required.

I think the second option would be more robust. For example you can do the 
following in the JavaParseJob using some of the new infrastructure:

if(globalProjectTopContext->parsingEnvironmentFile()-
>featuresSatisfied(TopDUContext::Recursive | 
TopDUContext::SimplifiedDeclarationsAndContexts))
{
 //All project-files have been processed at least in simplified mode, so now 
this top-context can be processed fully.
buildTopContext(features());
}
else
{
 //The project-files were not yet processed in simplified mode. We cannot 
resolve types yet, so we process this document only in simplified mode.
buildTopContext(TopDUContext::SimplifiedDeclarationsAndContexts);

 //Re-queue the document into the background parser
backgroundParser->addDocument(document(), features(), 10000 /* very bad 
priority, so the document is parsed after the first parsing run is finished 
*/);
}

This is slightly oversimplified, but it could work approximately like this.

Greetings, David




More information about the KDevelop-devel mailing list