Project motivation / VS Code / IDE support? about tolerant-php-parser HOT 7 OPEN

Thanks for reaching out @mindplay-dk. I have to admit that I haven't been able to put the time into this project that it deserved. I would like to keep it moving forward, and we have had a couple active contributors whose work I really appreciate. I would like to keep managing PRs, but I am pulled in multiple directions in my work and don't have the time to write a lot of code for it myself. So making any real progress here will require community effort.

We worked with the author of php-language-server awhile back, and my understanding was that it was actually used by Sourcegraph. I'm not sure whether they stopped using and developing it or just stopped open-sourcing it. Reached out to the author recently but haven't heard back.

And I wish we could do better with PHP but currently there is no plan to put more resources into it. Sorry that I don't have a better answer for you.

from tolerant-php-parser.

I'm one of the contributors - This is currently used by http://github.com/phan/phan as a fallback parser for parsing files that have syntax errors (I'm one of Phan's maintainers)

Does Microsoft have any plans to eventually do something in the PHP IDE space, like actually leverage this package for language server support for PHP? Or is that all up to the community?

E.g. this is used for the syntax error tolerance of the Phan language server client for vs code https://github.com/tysonandre/vscode-php-phan#error-detection-tolerating-syntax-errors (as well as a fallback if the PECL https://github.com/nikic/php-ast/ is not installed)

I'd asked maintainers of other static analyzers (that also included language server implementations)

• The last time I checked was years ago - at the time, this did a better job than https://github.com/nikic/PHP-Parser/ at tolerating method bodies with incomplete closing braces and properly parsing the rest of the methods, but this may have changed
• Currently, there are some open bugs in tolerant-php-parser for rare edge cases that are inconvenient - if someone had time to make a working PR it'd likely get reviewed, though
• Switching from parser implementations to others is a lot of work and a backwards incompatible change, so existing projects tend not to do this - approaches such as https://github.com/TysonAndre/tolerant-php-parser-to-php-ast can be used but make parsing take longer and require work to implement/support/test for combinations of parsers

from tolerant-php-parser.

@TysonAndre I've actually been rethinking this a bit. If an IDE only gets new type information when the syntax is valid, that's probably fine if it's able to track line history in the editor while the code is invalid. That is, if you insert/remove lines (etc.) is the editor able to maintain associations to information produced by the analysis engine. The editor would have to treat syntax errors and other metadata as two different entities - only the syntax information would update continuously while you're making a change, while the metadata would simply get remapped to existing line identities and wouldn't actually update until there are no syntax errors. This would probably work just fine, as syntax errors are usually very temporary - and generally get dealt with before making any other changes to the code.

from tolerant-php-parser.

Maybe I don't fully understand the point you're making, but I think that being able to get type information in files with syntax errors is important in the typical editing scenario, and is most important right next to the actual syntax errors, because this is where you are actively editing.

from tolerant-php-parser.

Maybe this is dependent on someone's personal work style, but I don't normally have more than one syntax error in a file at any given time - and it's usually at the site where I'm currently editing. Syntax errors are the first thing you have to fix, otherwise you can't run your program at all, right? So if only the first syntax error gets highlighted, that's probably fine. If other problems (type-checking errors etc.) only get updated when the syntax is valid, that's probably fine.

I guess I'm wondering how big a problem it really is. Again, this is assuming the IDE treats syntax and other analysis errors as separate entities, updates them individually, and maintains associations to the most recent analysis errors during edits.

I don't know, no big point here really, just wondering how critical error-tolerance really is to IDE support.

from tolerant-php-parser.

Getting type info from incomplete code is also important for other language features like intellisense, which you need right at the cursor, where code is invalid.

from tolerant-php-parser.

Getting type info from incomplete code is also important for other language features like intellisense, which you need right at the cursor, where code is invalid.

For auto-completion, yeah, I see what you mean.

from tolerant-php-parser.