Re: [pdt-dev] Semantic Analysis in PDT

[Dawid Pakuła <zulus@xxxxxxxxx>]

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ł (michal.n@xxxxxxxx) 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
pdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/pdt-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature