Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pdt-dev] Semantic Analysis in PDT
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 <zulus@xxxxxxxxx> 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.


-- 
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 :)


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

_______________________________________________
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

Back to the top