Java language support

[Niko Sams]

On Tue, Nov 24, 2009 at 12:09, David Nolden <zwabel at googlemail.com> wrote:
> 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.
We have the same issue for Php. This solution would work for us too. Probably
we could also have some language independent code in platform.

Niko