There's more that we should cover for string types:

https://3v4l.org/qJG1U
https://3v4l.org/mDX6U

But we'll do that in a separate rule. I'll create a new issue for that.

Hi, this is already (at least partially) covered by returning ErrorType from Type:: setOffsetValueType. So I suggest creating a rule that observes ArrayDimFetch in an assign operation and reports an error in case of ErrorType. This rule should pass these existing tests so it's possible it will be required to go through all the method implementations and improve them to return ErrorType in the right situations.

This kind of rule also has to respect levels - level 3 for always incorrect values and level 6 for partially incorrect values (unions where at least one type is fine).

@ondrejmirtes

This kind of rule also has to respect levels - level 3 for always incorrect values and level 6 for partially incorrect values (unions where at least one type is fine).

This PR already supports reportMaybes. Is that what you're asking for?

@iluuu1994 It would be nicer to employ RuleLevelHelper::findTypeToCheck, see how it's used elsewhere. It will also solve complaining about null which should be done only on level 7.

@ondrejmirtes One issue:

Currently, AssignOp are not added as assign expressions. This is because then expressions like $foo += 10; would not trigger an undefined variable $foo error. Unfortunately, for this rule this means that isInExpressionAssign will report false which will cause a false negative for this rule.

Modifying the NodeScopeResolver here:

https://github.com/phpstan/phpstan/blob/master/src/Analyser/NodeScopeResolver.php#L819

by adding || $node instanceof Expr\AssignOp will solve my issue but cause the other one described above.

Any idea on how to fix this?

Also, the rule is very redundant. The issue is that I need to filter the maybeTypes for expr and dim. Any tips on how to improve that?

@ondrejmirtes I don't see my PR in the dropdown 🤔

@ondrejmirtes The reason the build is failing is because of this. The tests already exist.

This one fails which is correct:

$value = 'Foo';
$value['foo'] = null;

This one should fail, but it doesn't:

$value = 'Foo';
$value['foo'] += null;

That is because $value['foo'] in $value['foo'] += null; is not recognized as an assignment expression which means the rule will ignore it (since we check isInExpressionAssign).

@ondrejmirtes Thanks 🙂

I've taken over this PR and created 56be6db, thanks :)

Cool 🙂