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