Linter Error "Classlike is not defined or imported anywhere."

[schipa]

After upgrading php-integrator-base from 2.1.13 with PHP 5.6.30 to 3.0.1 with PHP 7.1.7 all type annotations for self written classes show this linter error:

Classlike is not defined or imported anywhere.

By now I reindexed the project and restarted atom multiple times. Before upgrading everything worked fine.

System Info

OS: Win 10, x64 PHP: 7.1.7 x64 Atom: 1.18.0

atom-ctags@5.1.0
atom-ternjs@0.18.3
busy-signal@1.4.3
emmet@2.4.3
file-icons@2.1.9
highlight-selected@0.13.1
hyperclick@0.1.2
intentions@1.1.2
linter@2.2.0
linter-csslint@1.3.4
linter-htmlhint@1.3.3
linter-jshint@3.1.5
linter-ui-default@1.6.2
minimap@4.28.3
minimap-git-diff@4.3.1
minimap-highlight-selected@4.6.1
php-integrator-annotations@1.2.0
php-integrator-autocomplete-plus@1.6.0
php-integrator-base@3.0.1
php-integrator-navigation@1.2.1
php-integrator-refactoring@1.4.0
project-manager@3.3.5
split-diff@1.4.3
tabs-to-spaces@1.0.3

[jtraulle]

Same issue for me on macOS 10.13 Beta (17A306f) PHP 7.1.6 and Atom 1.18

[TitanNano]

same issue here too macOS 10.12.5 PHP 7.2.0beta1 (cli) (built: Jul 19 2017 21:56:52) ( NTS ) Atom 1.18.0

[Gert-dev]

Do none of your classes work? Are there any errors showing up during an "Index Project" operation (either as notification or in the developer tools)? Does a simple, separate project work?

[schipa]

A small simple project works fine.

---

On my main project I deleted all three project-related .sqlite* files and started a fresh index. There were no notifications. The dev tools state:

The PHP server has something to say: Starting socket server on port 22969...
php-integrator-base - Indexing: 264899.682ms

The linter error Classlike is not defined or imported anywhere. still remains. So I examined the related SQLite database.

---

The table File seems to contain all the indexed paths. But a whole subtree - in which said error occurs - is missing. It only contains .atom/packages/php-integrator-base/core/3.0.0/vendor/*, {PROJECT}/vendor/* and {PROJECT}/data/* (Doctrine ORM proxies).

When I open, edit and save a file from that subtree and reload table File, that file's path is added. The remaining subtree is still missing.

---

My projects.cson:

[
  {
    title: "OSM Backend"
    paths: [
      "T:\\osm\\backend"
    ]
    php:
      enabled: true
      php_integrator:
        enabled: true
        phpVersion: 7.1
        excludedPaths: []
        fileExtensions: [
          "php"
        ]
  }
]

[tgomesfork]

Same issue for me on

• Atom 1.18.0
• PHP 7.1.7
• Ubuntu 16.04.2 LTS

[Gert-dev]

@schipa If I understood correctly: if you edit a single file that is inside the subtree that is not indexed, it suddenly does show up in the File table?

In that case it is likely indexing of the files in the subfolder is skipped or broken off for some reason. File permissions seem unlikely as it does work when manually editing a file.

That leaves indexing errors, which would be really strange since:

• Problems with not being able to index a file because something is unexpected or unsupported should throw a big fat red error in Atom (or at least in the developer tools).
• A file not being able to be indexed due to parsing errors or permissions is just skipped (if you were able to get one of the subfiles indexed by editing it, it should have been indexed in the first place as no entire subfolders should be skipped).

What you could try is opening up ~/atom/packages/php-integrator-base/core/3.0.0/src/Indexing/ProjectIndexer.php at line 148 or somewhere else in the loop and try putting an echo $filePath . PHP_EOL; or similar there. If you restart Atom and force reindex your project afterwards, the output should show up in the Atom developer console and you can see if the file is passed or not.

[schipa]

If I understood correctly: if you edit a single file that is inside the subtree that is not indexed, it suddenly does show up in the File table?

Correct!

---

I added echo $filePath . PHP_EOL; in line 131 (right after $filePath assignment), restarted Atom and ran "Forcibly (Re)index Project".

The dev tools console only states

The PHP server has something to say: C:\Users\p.schimkus\.atom\packages\php-integrator-base\core\3.0.0\src\UserInterface\Command/../../../vendor/*
...
The PHP server has something to say: T:\osm\backend\data\DoctrineORMModule\Proxy\*
...
The PHP server has something to say: T:\osm\backend\vendor\*
...

The project path is T:\osm\backend, but indexing is jumping over T:\osm\backend\module\* (said subtree).

[Gert-dev]

This is getting stranger by the minute. Could you try commenting out the ModificationTimeFilterIterator, ExclusionFilterIterator, and ExtensionFilterIterator just above the loop? I don't expect this to be the issue (unless perhaps you have a filesystem without modification timestamps and the code is doing something weird with them as a result, instead), but it never hurts to rule out everything.

This should leave just the MultiRecursivePathIterator, which does the actual path scanning and should be returning all files and folders in your project tree. If it still doesn't show up, it may be worth opening up MultiRecursivePathIterator (it is rather small) to see if it is the culprit.

[schipa]

Could you try commenting out the ModificationTimeFilterIterator, ExclusionFilterIterator, and ExtensionFilterIterator just above the loop?

Still missing the subtree. I re-examined the File table - it turns out that parts of vendor/* are missing too.

---

I uncommented the three FilterIterators and replaced debugging in line 131 with echo ($i+1) . "/$totalItems # $filePath" . PHP_EOL;

Last two lines from the dev tools console:

The PHP server has something to say: 4524/5313 # T:\osm\backend\vendor\bin\pluginmap_generator.php
php-integrator-base - Indexing: 250880.560ms

So the iterator is in fact not missing the subtree but the process is dying beforehand. Strange that no error was given in that case.

vendor/bin contains symlinks!

Did this happen because of missing symlink handling or because I'm on Windows and T:\ is a Linux mounted via SFTP?

Either way, adding this path to php.php_integrator.excludedPaths and running an other reindex results in a complete index and the linter error Classlike is not defined or imported anywhere. is gone!

Maybe a symlink handling in MultiRecursivePathIterator.php#L48 could fix this!?

[Gert-dev]

Good to hear that we're getting closer.

I don't know what kind of symlink/SFTP mounting you are using in Windows, but IIRC Windows does not have any sort of native SFTP mounting (it does have FTP, I believe?), so it is very well possible that the software you are using to do this doesn't actually expose "real" folders in the sense that they iterate in the same way as other folders. On Linux systems "special" filesystems or remote connections such as SFTP can be mounted transparantly using software such as gvfs, so it should work there at least.

It could indeed also be related to symlinks, but if you look a couple of lines higher, symlinks are already followed when iterating the directory structure. The fact that the total also lists a high amount means that these files are actually included in the traversal. But I believe iterator_count actually forwards the iterator to the end, after which it is rewound in the foreach, which means the folders are actually scanned twice (which sounds like a performance hit, I should probably test that later). Perhaps the first iteration is yielding different results from the second for some reason. What happens if you manually set $totalItems to something like 5313 (and comment out the iterator_count)?

You can also try removing CATCH_GET_CHILD in the MultiRecursivePathIterator. It throws errors when folders can't be accessed, maybe this option is muffling some kind of error.

[schipa]

If I set $totalItems = 5313; it keeps dying at 4524/5313. Whatever number I set there, it dies at 4524. No errors given without CATCH_GET_CHILD.

---

I use SFTP Net Drive. I can open a symlink file and the code of the linked file is loaded but the dev tools state

Uncaught (in promise) Error: EISDIR: illegal operation on a directory, lstat
'T:\osm\backend\vendor\bin\pluginmap_generator.php'
    at Error (native)

$fileInfo->isLink() is false for T:\osm\backend\vendor\bin\pluginmap_generator.php. If I run dir in a CMD shell, it doesn't state <SYMLINK> (what it should do) for the symlinks in T:\osm\backend\vendor\bin. So SFTP Net Drive isn't exposing symlinks as such!

[neobyteUK]

Same issue for me, except I'm new to atom so I haven't upgraded from a previously working version.

OS: Ubuntu 16.04 Atom: 1.23.0 x64 PHP: 7.1.12

Trying to use Atom with a project I usually manage with PHPStorm. Basically the entire project flags up as "Classlike is not defined or imported anywhere".

Followed the instructions here (https://php.earth/docs/interop/atom) for my setup. I've tried re-indexing/restarting etc. Console shows an unexpected php socket close at the end of indexing.

This is quite an old issue, has someone found a workaround?

UPDATE:

After increasing the memory available to php-integrator-base from 1 to 2 GB in its settings and restarting Atom, my index completed successfully and classes resolved. Had a hunch after noticing in the integrator code that the PHP instance created seems to be being started with the same core.memoryLimit that was configured in integrator. Assumed PHP was running out of memory trying to index such a large project. Could be a total red herring but... I'm now working.

[Gert-dev]

@neobyteUK Glad to hear that fixed it for you!

I haven't been able to reproduce the exact same issue, but there is a somewhat similar issue where everything works one moment, you then open a file with a class you are using in the previous flie, switch back to the previous file without making any modifications, and all of a sudden the class is flagged as "not found", even though you didn't modify the file that contains it.

I've verified that the class disappears from the index (but not the file, strangely enough) and no index is supposedly happening, but I'm still figuring out how or why this is happening.

[Gert-dev]

I've fixed an issue in core 3.2.0 that caused files to disappear from the index sometimes. Could someone experiencing this problem verify that this still occurs?

[madrussa]

PHP-Integrator: 3.2.0 Atom: 1.23.3 PHP: 7.1.6

The indexer appears to be ignoring most things within my "vendor" directory, unless I edit a file. My vendor directory is in the root folder and also git ignored. It's a standard Lumen project (https://lumen.laravel.com/) with only modified & added files existing under the "app" directory. I've tried re-indexing and force re-indexing which haven't included the additional classes.

[Gert-dev]

@madrussa Unfortunately setting up a lumen project here via composer create-project --prefer-dist laravel/lumen blog as described on the site and setting that up seems to work without issues for me. This does not mean there isn't a bug, however, but it makes it harder to figure out what exactly is going wrong.

Does anything strange about your setup come to mind, such as having files on an (S)FTP server on Windows as previously described, or messages showing up in the developer tools console? Another thing you could try is following the instructions previously posted here about debugging the core - note that the file to go to has now changed to this one due to refactoring.

[madrussa]

We have a few large packages included which could be slowing things down. I noticed the indexer running continuously for two days now approx 14hrs.

{
    "php": ">=7.0",
    "nesbot/carbon": "~1.22",
    "laravel/lumen-framework": "5.4.*",
    "vlucas/phpdotenv": "~2.2",
    "guzzlehttp/guzzle": "^6.1",
    "spomky-labs/otphp": "^6.0",
    "appzcoder/lumen-routes-list": "^1.0",
    "doctrine/dbal": "^2.5",
    "squizlabs/php_codesniffer": "*",
    "soapbox/laravel-formatter": "^2.0",
    "php-amqplib/php-amqplib": "^2.6",
    "goodby/csv": "*",
    "filp/whoops": "^2.1",
    "illuminate/mail": "v5.4.*",
    "aws/aws-sdk-php": "^3.28",
    "bramus/monolog-colored-line-formatter": "~2.0",
    "astrogin/laravel-mysql-spatial": "^1.0",
    "dusterio/laravel-plain-sqs": "^0.1.8",
    "zendframework/zend-soap": "^2.6",
    "symfony/psr-http-message-bridge": "^1.0",
    "fideloper/proxy": "^3.3",
    "phpoffice/phpspreadsheet": "^1.0",
    "mpdf/mpdf": "^7.0",
    "jpgraph/jpgraph": "^4.0",
    "dompdf/dompdf": "^0.8.0"
}

I'll implement the core bugging and let you know how I get on.

[arnair-incomm]

Mac OS High Sierra Atom 1.24.0 PHP 7.1.14

Needed to index a large project (Magento 2.2.2 EE). I had to increase core memory to 8GB and then only indexing finished. Looks like it is still using the whole memory allotted. Possible memory management issue?

I am able to see class hinting now.

[cjcox17]

Windows 10 w/ WSL Atom 1.24.0 PHP 7.1.16

I had a fix by increasing memory to 4GB. The process now sits at 2.7GB after indexing, pretty hefty. The issue also occurs when using the new syntax

use App{One, Two, Three, Four, Five};

It doesn't seems to understand multiple classes on the same line. If I split them into separate lines all of the errors go away.

[twifty]

Just ran into this myself.

namespace In2it\HelloWorld\Test;

use PHPUnit\Framework\TestCase as Foo;

class HelloTraitTest extends Foo\Framework\TestCase {}

The docs say:

How does a name like my\name resolve? ¶ Names that contain a backslash but do not begin with a backslash like my\name can be resolved in 2 different ways.

If there is an import statement that aliases another name to my, then the import alias is applied to the my in my\name.

Otherwise, the current namespace name is prepended to my\name.

So, the above example extends should map to \PHPUnit\Framework\TestCase\Framework\TestCase, however the linter is complaining about it not being defined/imported.

[Gert-dev]

@twifty You are correct (and the docs are too, of course), though it is likely that it is not that this isn't resolving correctly, but rather that for some reason the TestCase class somehow disappeared from the index or wasn't indexed at all - at least, that is what is causing most of the pain in this issue, I believe.

In other words, the example is supported and should work, but I have yet to figure out why on rare occasions the core bails the file out of the index :thinking: .

[Gert-dev]

I think I've (finally) identified what the problem is. (I don't know how this suddenly occurred to me, since I wasn't looking for it in particular.) Every time the core/server is updated, the version number changes (obviously). This version number is taken up into the path to the core as the folder it is in is named after the version.

When a new project is set up, the built-in stubs are indexed first, but these are stored in the vendor folder of the core itself. Because their path changes on update, the core prunes files that no longer exist from the index, and built-ins are only indexed once, these were being removed but never readded.

I've confirmed and fixed this issue. I still need to give it a bit of testing, but everything works fine, I'll release it soonish.

I've also fixed another issue pertaining to user-defined classes sometimes disappearing when closing files after modifying them and before they had a chance to index, which was another pesky one that has been around for quite some time.

[AmirHosseinKarimi]

Hi, Is this problem fixed? I have it on the latest version of Serenata and Atom...

[CreationTribe]

Yeah, I'm running into this as well. New version of Atom, new version of Serenata.

[Gert-dev]

It will definitely be in 5.0!