Skip to content

Conversation

@sbomer
Copy link
Member

@sbomer sbomer commented Nov 17, 2023

Adds a helper that's used in the default case whenever we switch on the IOperation type, that:

  • skips invalid operations
  • skips unexpected operations with nested invalid operations
  • skips INoneOperation
  • asserts throws otherwise, in Debug mode

Fixes #94858
Fixes #94260

@sbomer sbomer requested a review from vitek-karas November 17, 2023 01:41
@sbomer sbomer requested a review from marek-safar as a code owner November 17, 2023 01:41
@ghost ghost added linkable-framework Issues associated with delivering a linker friendly framework area-Tools-ILLink .NET linker development as well as trimming analyzers labels Nov 17, 2023
@ghost ghost assigned sbomer Nov 17, 2023
@ghost
Copy link

ghost commented Nov 17, 2023

Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @sbomer, @joperezr, @marek-safar
See info in area-owners.md if you want to be subscribed.

Issue Details

Adds a helper that's used in the default case whenever we switch on the IOperation type, that:

  • skips invalid operations
  • skips unexpected operations with nested invalid operations
  • skips INoneOperation
  • asserts otherwise, in Debug mode

Fixes #94858.
Fixes #94260

Author: sbomer
Assignees: -
Labels:

linkable-framework

Milestone: -

break;
case IInvalidOperation:
// This can happen for a field assignment in an attribute instance.
// TODO: validate against the field attributes.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked that the current behavior doesn't give IInvalidOperation for field assignments in attribute instances - possibly fixed by some recent work that touched the way we do attribute analysis. While I was touching AttributeFieldDataflow I cleaned it up a bit, along with the similar testcase AttributePropertyDataflow.

// but do not throw here as it means new Roslyn version could cause the analyzer to crash
// which is not fixable by the user. The analyzer is not going to be 100% correct no matter what we do
// so effectively ignoring constructs it doesn't understand is OK.
Debug.Fail ($"{targetOperation.GetType ()}: {targetOperation.Syntax.GetLocation ().GetLineSpan ()}");
Copy link
Member

@stephentoub stephentoub Nov 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use release builds of the analyzer in local development? Such asserts make it really hard to continue working when they occur. Or something else besides an assert.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed back to throwing like we used to, but only in Debug builds. This should surface as AD0001 warnings, which can be silenced if needed, while still giving us feedback on any analyzer crashes. Related to the discussion in #90358.

This should produce AD0001 instead
Copy link
Member

@vitek-karas vitek-karas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good - thanks a lot!

@sbomer sbomer merged commit f067016 into dotnet:main Nov 21, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Dec 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Tools-ILLink .NET linker development as well as trimming analyzers linkable-framework Issues associated with delivering a linker friendly framework

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Asserts in ILLink analyzer Asserts from ILLink analyzers

3 participants