From kdevelop-devel Mon Feb 13 09:54:02 2012 From: David Nolden Date: Mon, 13 Feb 2012 09:54:02 +0000 To: kdevelop-devel Subject: Re: Dependencies of parse-jobs Message-Id: X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=132912700301542 2012/2/12 Sven Brauch : > Hi there, > > PovAddict and I were tracking a bug (in the python plugin) a few days > ago which turned out to be caused by the order in which documents are > parsed to be wrong (as in, not like I wanted it to be, heh). > Currently, I'm doing this: If document A is parsed and an "import" > (same like #include in c++) is encountered, a parse job is created for > the imported document using > =A0 =A0DUChain::self()->updateContextForUrl(...) > with a priority that has a lower value than the current parse job (and > thus a higher priority (who invented this?)). Then the current This one was my fault, I followed the linux priority logic, which later showed to suck hard. :-) > document is marked as "needs update", and after the parse job > finished, it's registered for a re-parse again (that's done inside > parsejob::run) with a lower priority than it had before (I'll use the > word "priority" as everybody expects it to be used from now on): > =A0 =A0KDevelop::ICore::self()->languageController()->backgroundParser()-= >addDocument(...) > Now, that roughly works, but not quite; sometimes, the documents are > not parsed exactly in the order their priorities suggests. I guess > that is to be expected -- but what else is there except priorities > that can be used to "sort" parse jobs? > > Here's the TL;DR version: What's the "good" way of forcing document A > to be re-parsed as soon as there's a top-context for B available which > satisfies the required $minimum_features? How does C++ do this? I > looked into the code, but couldn't quite find anything related to that > (it's a huge project...). > > Any help would be appreciated. :) > > Greetings, > Sven In C++, included documents may depend on other documents included earlier, and thus they must be parsed right in-place. You could do the same, by simply creating a new parse-job in-place and starting it recursively. You just need to care about preventing infinite recursion and multiple running parse-jobs f=FCr the same document. The question is what would be the correct way to deal with such recursion. In a language where such recursion is allowed, the correct solution would probably be a multi-pass parsing: When you encounter an include, parse it in a "simplified" mode (just creating declarations for the symbol-table, but without building uses and/or types etc.), and later re-parse it in full mode after the "simplified" mode has been finished for all includes. Greetings, David -- = KDevelop-devel mailing list KDevelop-devel@kdevelop.org https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel