Jan Nedbal

Sure, you can do this easily with [AST-based customization](https://github.com/shipmonk-rnd/dead-code-detector/?tab=readme-ov-file#ast-based-customization). This specific usecase also feels like it might even be natively in this repo, WDYT?

> tests describing what this actually fixes would be nice It is pretty painful to test new doctrine here (due to all the compatibility hacks). But added.

> Would it be possible to read the options ? Yes, implemented.

I'm not sure if there is any native functionality to test against. I need this function for [proper dead-code analysis](https://github.com/shipmonk-rnd/dead-code-detector/pull/48/files#diff-98f320f8c7e46825ecec63dc14e12ad45264cb78c54b41c75b15fe30a0b3d6cfR185).

Added a test and rebased on top of 2.0.x

Seeing the integration test failures, this is often triggered when numeric operation is performed with mixed. E.g. `$array[$mixed - 1]` as `$mixed - 1` is `float|int`.

Saying **often** is maybe too abmitious, I checked few :) ---- It would be great if integration tests used `editorUrlTitle` so that you can easily click-to the GitHub source.

Altough I agree with your points, I'm not sure I'll invest the time into all that. Mostly because the core issue is covered in our (even stricter) rule: https://github.com/shipmonk-rnd/phpstan-rules/pull/254

> So what about @phpstan-error An exact error message that works the same way as @phpstan-ignore with an error identifier in 1.11.x? I'm not sure that the next-line magic is...

For the meantime, we open-sourced our solution to a standalone package with just this functionality (inline error asserts in tested code): https://github.com/shipmonk-rnd/phpstan-dev