Hi, Great plans you have both for semantic analysis :-)
I wonder if we could start small for Mars.1 and just introduce the semantic analysis framework "as is" from either PEX or Zend Studio. Just the framework - the only check for now will be the one for unused use statements that we've just merged. This will allow users to control this new feature, i.e. set Error/Warning/Ignore for the check, and won't affect the performance. The adaptation efforts in both PEX and Zend Studio should be also minimal at this stage. Then for Mars.2 we can gradually improve this with the ideas mentioned. What do you think? Kaloyan On Fri, Aug 14, 2015 at 1:41 AM, Dawid Pakuła <[email protected]> wrote: > Hi, > > good to know. Current PEX framework is written (broken :P) mostly by me > and based on this experience I’m designing new version which I planned to > propose as PDT plugin. Probably for Mars.2 (performance is critical part > for me). > > Separate to “require / not require” index isn’t enough, because still will > be slow. Even with index. Index usage might be also easy reduced by class > loaders (see bug 472758 [1] }:->). > > A lot of problem could be collected during standard Type Inference (JDT > calls this flow analysis) : class / variable / method not exists or even > deprecated calls . DLTK don’t allow collecting IGoal results during > inference process right now. I plan to propose patch, because I need it to > improve syntax highlighters performance, especially deprecation highlighter. > Others need access to type information (implementation / override etc…) > so as you said index (or class loaders helpers). > Others need only content / ast > Others, mostly framework specific, might need three of above or nothing > (own index/builders etc…). > Also validator chain should be introduced. If any validator produce > problem, validator participant should be able to mute / extend (ideal use > case could be usage validator where doctrine extension could). > > but if we talking only about ui (user point), would be nice to have not > only categories and validator names with severities, but also ability to > introduce some options to validator (for example be case sensitive) like in > JDT. > > [1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=472758 > > -- > Dawid Pakuła > +48 795 996 064 > > On 13 Aug 2015 at 23:47:09, Michał Niewrzał ([email protected]) wrote: > > Hi All, > > I want to start discussion around semantic analysis in PDT. This topic is > covered in PDT Extensions and also in Zend Studio. Now we have first SA > rule in PDT[1]. I think it is time to provide base for SA in PDT. One point > where all extensions can add own validators in ordered way. > > From technical point of view I don't have full vision how it should look. > I think main change is to choose best approach how/when validate source > code. For many checks full indexing is necessary for other only AST tree. > To start with something I will write few ideas: > * one common preference page, categories similar to JDT > * maybe each extension can add own tab to this page to avoid confusion > with doubled validators > * provide two types of validators: > * basic - no indexing data needed, can be triggered by IBuildParticipant > * advanced - indexing data necessary, triggered after indexing > * users can on/off both types separately > * maybe we can think about validation only on demand or on file open to > avoid extending build/indexing time > > As I wrote it's only general description what is in my head but it will be > easier to comment :) > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=354782 > > Michal > _______________________________________________ > pdt-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/pdt-dev > > > _______________________________________________ > pdt-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/pdt-dev >
_______________________________________________ pdt-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/pdt-dev
