-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reference live ILLink analyzer #93259
Conversation
- Fix some analyzer asserts - Reference local analyzer - Fix property initializer behavior
Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas Issue DetailsIn #91233 I inadvertently turned off the trim analyzer for libraries, because the analyzer bits don't flow to the consuming project with the ILLink.Tasks ProjectReference. This adds a separate ProjectReference to use the live analyzer. This addresses #88901 for the ILLink analyzers. Using the live analyzer uncovered some bugs that are fixed in this change:
|
src/tools/illink/src/ILLink.RoslynAnalyzer/DataFlow/LocalDataFlowVisitor.cs
Outdated
Show resolved
Hide resolved
CI uncovered another assert, which I'm fixing separately in #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.
I fixed a few more asserts that came up after #93420:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also verified that this change doesn't require updating our solution files again in src/libraries.
Test failure looks like #90019 |
In #91233 I inadvertently turned off the trim analyzer for libraries, because the analyzer bits don't flow to the consuming project with the ILLink.Tasks ProjectReference. This adds a separate ProjectReference to use the live analyzer. This addresses #88901 for the ILLink analyzers.
Using the live analyzer uncovered some bugs that are fixed in this change:
throw
statementsIMethodSymbol
for the ContainingSymbol of a local. Locals can occur in field initializers, when created from out params.Type AnnotatedPropertyWithSetter { get; set; } = GetUnknown ();
(IIRC I hit this one when investigating some related behavior, not via a new warning produced when analyzing runtime)