Java language support

Hamish Rodda rodda at kde.org
Tue Nov 24 10:37:27 UTC 2009


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?

Cheers,
Hamish.




More information about the KDevelop-devel mailing list