Bug #66773 [Com]: Autoload with Opcache allows importing conflicting class name to namespace

Edit report at https://bugs.php.net/bug.php?id=66773&edit=1

 ID:                 66773
 Comment by:         incubeftw at gmail dot com
 Reported by:        carl dot vuorinen at w3 dot fi
 Summary:            Autoload with Opcache allows importing conflicting
                     class name to namespace
 Status:             Assigned
 Type:               Bug
 Package:            opcache
 Operating System:   Linux (Ubuntu)
 PHP Version:        5.5.9
 Assigned To:        dmitry
 Block user comment: N
 Private report:     N

 New Comment:

Bug still persists in PHP 7.0, 7.0.1, 7.1-dev


Previous Comments:
------------------------------------------------------------------------
[2015-12-14 10:55:02] pawel dot zegardlo at bm dot pl

@dmitry - what is the state of this bug? it has been fixed in php 7 or another version? which behaviour is now valid?

------------------------------------------------------------------------
[2015-07-06 04:22:57] kernins at gmail dot com

>Isn't the "expected" error behavior here directly in conflict with the documentation?

Absolutely! The actual bug here is the "expected" behaviour itself. The code in some_foo.php from test example is perfectly valid as imports are _per_file_, not per process or thread. Imports have precedence and allows to "shadow" classes from current NS, and they shouldn't care what is already loaded or imported, except from current file. Otherwise, with "expected" behaviour, they not only would be alogical and almost useless, but also a hell to maintain in a big projects.


I have a project, that worked perfectly on some older 5.4.x and all previous versions I've used since NS was introduced in 5.3. But after update to 5.5.9 I see exactly the same fatal errors here and there on previously flawlessly working code when runing in CLI. Opcache is and definitely was turned off for CLI SAPI. With FPM, wich has opcache enabled, it worked fine.

It seems, that bug was also backported to 5.4 branch - 5.4.34 I have on hand is also affected, but I'm absolutely confident some previous 5.4.x was not.

Please, fix this nonsense asap! This bug is pretty annoying

------------------------------------------------------------------------
[2015-06-02 13:53:53] Erutan409 at Hotmail dot com

Has this been resolved, yet and/or is this still considered a bug?

------------------------------------------------------------------------
[2014-11-07 17:15:44] john at zerocrates dot org

Isn't the "expected" error behavior here directly in conflict with the documentation?

http://php.net/manual/en/language.namespaces.faq.php#language.namespaces.faq.conflict

That documentation section gives the following example:

file1.php
---------
<?php
namespace my\stuff;
class MyClass {}
?>

another.php
-----------
<?php
namespace another;
class thing {}
?>

file2.php
---------
<?php
namespace my\stuff;
include 'file1.php';
include 'another.php';

use another\thing as MyClass;
$a = new MyClass; // instantiates class "thing" from namespace another
?>

So, in file2.php, once the includes are done, the class name "my\stuff\MyClass" is already "in use." But, the documentation says that the "conflicting" use statement "use another\thing as MyClass" should be fine, so long as the other MyClass is declared in another file (which it is). On this subject the documentation says:

"There is no name conflict, even though the class MyClass exists within the my\stuff namespace, because the MyClass definition is in a separate file."

Other than the use of autoloading, I can't see any distinction between that example and the test script here, and it doesn't seem like the autoloading should make any difference.

------------------------------------------------------------------------
[2014-10-23 15:40:45] [email protected]

I think all we need to do is drop the if (+ 10 lines) at http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_compile.c#4723, which checks whether a class with the imported name already exists.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=66773


--
Edit this bug report at https://bugs.php.net/bug.php?id=66773&edit=1