This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Runtime.php is not indexed in new projects. It is probably missing in the classpath. As a result code completion for standard PHP functions, classes and constants is longer working in new PHP projects.
No change in PHP classpath package for several weeks (maybe months) - I will look at it.
It looks like the class path is OK. On the other hand sometimes not even the currently edited file is indexed. I think yesterday it was still working fine... possibly this is a regression in GSF
Nothing has changed in this area in GSF. Is this 100% reproduible? Can somebody give me very specific instructions for how to reproduce the problem? I'll start playing with it but some hints might save me some time.
Runtime.php is not indexed 100% of the time. It is a signature file that resides in nb_home/debug/config/PHP/RuntimeLibraries/runtime.php. It is on every project's boot class path.
I just thought maybe the problem is in my indexer code and the infrastructure is eating exceptions again. Don't have time to check it right now...
How are you confirming that Runtime.php does not get indexed? Have you set breakpoint and confirmed that during startup on a blank userdir it wasn't called? Or are you checking some editor feature (e.g. code completion) for an API that should come from Runtime.php and it doesn't show up? Just want to make sure I can reproduce this. I don't know PHP, and it sounds like this bug isn't 100% reproducible and I want to know what the P1 symptoms are.
I looked at the project part and the result is - runtime.php is created in clean userdir and its parent directory is included in BOOT classpath. If I can help more, let me know. (The only change in classpath package in the last week was done by Quy Nguyen but this definitely cannot be the cause of this issue.)
What do I do in the IDE to verify that something is wrong? Is there a particular user source I can use and code completion expression to see that something is broken?
Tor, just create a new PHP project and in the opened file index.php try (between <?php and ?>): str| strlen() function should be offered by CC.
Thank you, I can reproduce the problem. I'm investigating now.
I discovered why this suddenly surfaced. I made JSON its own mimetype/gsf language yesterday. It's subclassing most JavaScript services. One of the things it therefore extended was the indexer. And the JavaScript implementation of the indexer indexes PHP files, which the new JSON language therefore also would do. This caused a problem because there was now an additional language saying it's interested in PHP files, and that has exposed a bigger and deeper problem in the way files are parsed/indexed during startup indexing. The root bug is still there, and I will be looking into that next, but I've overridden the indexer registration in JSON now such that it doesn't have an indexer anymore, which should restore things to the way they were (this is in changeset b38653923f79). Hopefully that means things will begin working better in PHP again. But the deeper bug is still there, so I'll leave this issue open while I'm working on it.
Tor, thanks for the evaluation and finding the problem.
Okay, this should be fixed properly now. The root cause (which has been there from 6.0 and 6.1 as well) was that during startup indexing, only the FIRST file to register an interest in a file, actually got to index it! This wasn't discovered until now for a couple of reasons. First, interactive indexing (e.g. "on demand" indexing when you're doing code completion and request completion) DOES index all language types, so if you for example went in a JavaScript file and tried to access a local function, that would work just fine. Second, this only affects file types which have multiple interested indexers. That pretty much only means PHP today, since for other such types (HTML/JSP/RHTML) it's not as common to have embedded function definitions (except for the interactive indexing scenario mentioned above). E.g. you don't typically reference the JavaScript method defined in one HTML file from another file. Thank you guys for exposing this bug!! The reason this suddenly surfaced was that there suddenly was a new file registering interest in PHP files - and by luck or accident, in some cases that other indexer would get the first chance to index the file, and therefore take away PHP's turn. This fix touches some very sensitive code so please keep your eyes open for any other issues - files not getting indexed when they should, timestamp computations no longer working in all cases (reindexing unchanged files etc). I've tested this a bit and things look good but since this is critical code I want to make doubly sure it's okay. Fixed in changeset edf81c9b1954.