You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix analyzer treatment of flow captures of arrays (#93420)
#93259 uncovered an issue
around how the analyzer tracks arrays. It hit an analyzer assert
while trying to create an l-value flow capture of another flow
capture reference, which should never happen as far as I
understand. The assert was firing for
https://github.com/dotnet/runtime/blob/946c5245aea149d9ece53fd0debc18328c29083b/src/libraries/System.Private.CoreLib/src/System/IO/RandomAccess.Windows.cs#L511
Now tested in TestNullCoalescingAssignment:
```csharp
(arr ??= arr2)[0] = typeof (V);
```
The CFG had three flow captures:
- capture 0: an l-value flow capture of `arr`. Used later in the
branch that assigns `arr2` to `arr`.
- capture 1: an r-value flow capture of capture 0. This was
checked for null.
- capture 2: an l-value flow capture representing `arr ??= arr2`,
used to write index 0 of the array.
- In the == null branch, this captured the result of an
assignment (capture 0 = `arr2`)
- In the other branch, it captured "capture 1". This is where
the assert was hit.
The bug, I believe, is that capture 2 should have been an r-value
flow capture instead. Even though it's used for writing to the
array, the assignment doesn't modify the array pointer
represented by this capture - it dereferences this pointer and
modifies the array. This was introduced by my modifications to
the l-value detection logic in
#90287.
This undoes that portion of the change so that capture 2 is now
treated as an r-value capture. This simplifies the array element
assignment logic so that it no longer can see an assignment where
the array is an l-value.
Fixes#93420 by adding an
explicit check for `IsInitialization` so that we don't hit the
related asserts for string interpolation handlers.
0 commit comments