Support `@noinspection` annotations for diagnostics

[bmewburn]

[saippuakauppias]

How to use @noinspection with error code?

Like #pragma warning( disable : 4507 ): https://docs.microsoft.com/en-us/cpp/preprocessor/warning?view=vs-2019

[KapitanOczywisty]

@saippuakauppias Intelephense doesn't support that and probably will not in the near future. Other editors/analyzers may use non standard implementations e.g. phpStorm, Psalm

[yaegassy]

@bmewburn @KapitanOczywisty Any progress on this feature addition?

[abuyoyo]

Any progress on this? This seems to be a common feature request.

[Lachee]

This is actually a rather annoying thing not to have. Standard PHP libraries tend to throw these errors because they use non-conventional folder structures (for some reason).

My current use case is the MongoDB library, and the \MongoDB\BSON\ObjectId object. Would be nice to be able to tell Intelephense to ignore this.

Note: I do like the proposed syntax /* intelephense-disable */ as it matches other linters, but a phpdoc style annotation would probably be the best way to go. Would be awesome if we could give it specific error codes too.

[piotr-cz]

This would be really helpful when using 3p packages that have wrong return types in their docblocks.

[yookoala]

Recently stumbled upon an issue with PHP's ReflectionType. If you use the documented ReflectionType::__toString, intelephense would tell you it is deprecated and please use "getName" instead.

But the preferred method ReflectionType::getName, although exists, is undocumented still as of this moment. So if I use it, I'll get Undefined method 'getName'.

This is quite annoying. So I'd want to disable the clearly nonsensical "error" message. But I can't even do that.

You may use this piece of code to experience the madness:

<?php

class Dummy {}
$ref = new \ReflectionFunction(function (Dummy $dummy) {});
$type = $ref->getParameters()[0]->getType();

// bummer 1: method '__toString' is deprecated. intellephense (1007). please use 'getName()'.
$type->__toString();

// bummer 2: Undefined method 'getName'. intellephense (1013).
$type->getName();

[underdpt]

Would like something like this implemented. This is also annoying on legacy projects (without autoloader), or on projects where you don't have all the dependencies on the project folder (my use case: a legacy project tha "lives" inside a Joomla site, the project uses joomla's libraries and constants, but phpintelephense has no way to get to those dependencies).

My preferred solution would be a per-project config file, where you can disable specific items (so no disabling all 'Undefined type' errors, but you can disable all 'Undefined type' errors referring to 'JRequest', for example).

Also this allows the developer to use the file only internally or to be used by the whole team (by means of .gitignore) and whenever you need you can enable those warnings globally by simply commenting them on the config file.

Or maybe use the vscode config system, and then you can disable warnings globally, per workspace or per folder.

My 2 cents.

[erickcomp]

I stumble in theses kind of errors when I use "$this->whatever" inside a closure, because the linter has no way of knowing where the closure will be binded at that moment. Being able to disable this kind of line would be awesome.

[furopi]

Me also likes the idea of that kind of functionality! Hope it gets implemented...

[Stetzon]

@bmewburn pls

[cyphun]

I would also love to see support for this.

[joshuapack]

Over a year and still no support. at least give it to paid users 🙏

[jspassov]

Any progress on this?!?

It's make almost impossible to use intelephense for Magento 2 PHP development.

[amunozj]

It would be amazing to get progress on this.

[navigatrum]

My use case: vendor libraries in docker volume A

• my plugin development on host in shared docker volume B

---

= a ton of php/js etc. code which doesn't need to be indexed = no need to multiply by seven the age of my PC to explain why it's so blazing fast = you feel like Antimalware Service Executable isn't melting even the ice in your fridge

[TonyGravagno]

Another use case in support of this enhancement:

function set_constants($prefix) { define($prefix . '_SUFFIX', true); ... } set_constants('THIS_APP') ...

if (THIS_APP_SUFFIX) {}

Results: "code": "1011", "severity": 8, "message": "Undefined constant 'THIS_APP_SUFFIX'.", "source": "intelephense"

Thanks!

[rodrigoodev]

Any progress on this?!?

[olliescase]

I would love to use this -- my issue is that I'm trying to write a parser for exceptions into responses, and a lot of them implement specific methods that don't inherit from a single interface / parent.

So in my case I use a reflection class to test for a method existing to extract certain information about it:

<?php
// ....
public static function fromException(\Exception $exception): JsonResponse
{
    $refException = new \ReflectionClass($exception);
    // ...
    if ($refException->hasMethod('getStatusCode')) {
        $responseCode = $exception->getStatusCode(); // This flags as undefined
    }
    // ...
}

Within my repository, this 'getStatusCode' method exists on, for example, an AWSException, a Symfony HttpException, etc. So testing for inheritance isn't feasible. I know this isn't perfect code -- someone could arbitrarily define a getStatusCode function that doesn't do what I expect, or returns a non-http-standard status code, but for my purposes this is good enough and its annoying to have it tell me there's a problem in the file when I know that method exists...

[realjjaveweb]

This is really needed also for features that are not-yet-supported e.g. like a Trait accessing a constant on the final class using the trait. Let's say self::SOME_CONST which is completely valid code and even can be checked like defined('self::SOME_CONST'). PHPStorm does this check by static analysis and checks whether the constant is defined somewhere in the classes where the Trait is used.

Syntax-wise I'd suggest something that is specific to intelephense and only one-line-ish like // @intelephense-ignore-line like phpstan does, or even better, ignore just that specific error like pylint does # pylint: disable=something-specific, something-else-specific

[mikkorantalainen]

I think the system should allow disabling selected tests/checks with workspace wide (or even user wide setting) instead of needing to add extra markup in the actual source code. When you maintain code in a team and each team member can choose their own tools (e.g. Eclipse vs PhpStorm vs VS Code vs Vim), adding tool specific hacks into the source code is no longer an acceptable solution.

[UVLabs]

Any update on this? @bmewburn as you can see we're yearning for it..many use cases have been presented as to why this is needed

[KreisonReis]

Any update on this? 👍

[VandaliaDigital]

Any update on this?

[HammSoftware]

Please implement this.

[andrei-dascalu]

I think the system should allow disabling selected tests/checks with workspace wide (or even user wide setting) instead of needing to add extra markup in the actual source code. When you maintain code in a team and each team member can choose their own tools (e.g. Eclipse vs PhpStorm vs VS Code vs Vim), adding tool specific hacks into the source code is no longer an acceptable solution.

May depend on use case, but for me I wouldn't like a workspace wide setting. Case in point

        /** @var MessagesApi $messages */
        $messages = $this->client->messages;

Where client is the MailchimpTransactional client that defines a dynamic property "messages". It exists, but intelephense fails to see it. I'm typehinting it specifically and PHPStorm accepts this (eg: if I've typehinted it, then it's there). Intelephense doesn't care and still tells me there's an error.

I wouldn't want to disable the check across the workspace, it's a valid check.

[LiamKearn]

Hi @bmewburn,

Here to once again to ask if you money can buy your time? Any updated thoughts since the last time someone brought it up?

I'm more than happy to contribute a subscription fee for my license if it enables you to work on common features like this. I'd even be happy to contribute to crowdfunding on a feature by feature basis if we were given a nice roadmap of ~rough dates or at least more frequent updates.

I absolutely understand if this is not the route you want to go down I've just seen it brought up a few times.

Maybe it's time to make a definitive issue on how often you will be maintaining this product and if we can assist you finically or not. If something like that was pinned in issues I think we'd save a lot of GitHub comments.

[alezanlongo]

Why not just turn off diagnostics for non-existent methods and properties?

[realjjaveweb]

@alezanlongo

Why not just turn off diagnostics for non-existent methods and properties?

That's not the point of this thread - that would report NO undefined methods or properties - the intention is to generally report undefined methods & properties, but have an option to make an exception to the rule when necessary.

[yookoala]

Why not just turn off diagnostics for non-existent methods and properties?

Because the feature is helpful in 99% of the situations. Adding the @noinspection or @noinspectionline annotations allow developers to iron out the odd 1% case when they know its needed without sacrificing the other 99% cases.