Martijn Faassen

Sorry to be MIA, I focused on other parts of my project for a while. It's great you made progress! Is there a way we can collaborate on it?

@xenira I'm planning to do some preparatory refactoring first. I didn't know there was a CI issue, good you're looking into that.

I've delved into the code somewhat but I still don't have a fix. In `crates/macros/src/module.rs` there's an `impl Describe` which generates the implements information that is then, I think, later...

Hm, I was wrong about the unwrap. It somehow takes place in ```rust pub fn arrayaccess() -> &'static ClassEntry { unsafe { zend_ce_arrayaccess.as_ref() }.unwrap() } ``` So perhaps this code...

There seems to some module startup code that initializes these classes, so apparently that's not being run during stub generation. I looked at introducing the right PHP class names like...

@xenira Hey! Glad to see someone else is looking into this! If you think it would help to chat on discord or something to debug this together, let me know!

I guess it's not possible to make the PHP context exist using `cargo php stubs`? By saying "use the interface name" you mean this? `#[implements(ArrayAccess)]` That would be a better...

So if `ClassEntry::try_find` indeed also finds PHP-defined interfaces, this would actually support a new use case too. An argument for using "ce::foo()" is discoverability: you can find that the PHP...

Yeah, I realized that the PHP defined interfaces wouldn't be available too. I still think it would be useful: PHP ecosystems likely exist that define new interfaces outside of the...

The error in question appears to be caused by `lookup_class_ex` in `zend_inheritance.c`, as that's the only place in the C code where this message seems to be generated. It's interesting...