Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Remove analyzer workarounds for using declarations #39324

Closed
wants to merge 1 commit into from
Closed

Remove analyzer workarounds for using declarations #39324

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 0 additions & 7 deletions ...atures/Core/Portable/DisposeAnalysis/DisposeObjectsBeforeLosingScopeDiagnosticAnalyzer.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -125,13 +125,6 @@ private void PerformFlowAnalysisOnOperationBlock(
ComputeDiagnostics(disposeDataAtExit, notDisposedDiagnostics, mayBeNotDisposedDiagnostics,
disposeAnalysisResult, pointsToAnalysisResult);

if (disposeAnalysisResult.ControlFlowGraph.OriginalOperation.HasAnyOperationDescendant(o => o.Kind == OperationKind.None))
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @chsienki. On second thought, I am wondering if we should leave these checks in place to future proof the analyzers from false positives in case of future language features with unimplemented IOperation support.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did wonder that too. Perhaps we should Debug.Assert? Given that we shouldn't have none operations in reality, it will stop anything breaking, but save as a catch for future language features?

Copy link
Contributor

Choose a reason for hiding this comment

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

Unfortunately, we do have bunch of nodes generated with OperationKind.None due to pending IOperation support (attributes, query clauses, unsafe code, VB xml literals, etc.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah ok. I guess we'll just leave this as-is then.

{
// Workaround for https://github.com/dotnet/roslyn/issues/32100
// Bail out in presence of OperationKind.None - not implemented IOperation.
return;
}

// Report diagnostics preferring *not* disposed diagnostics over may be not disposed diagnostics
// and avoiding duplicates.
foreach (var diagnostic in notDisposedDiagnostics.Concat(mayBeNotDisposedDiagnostics))
Expand Down
11 changes: 0 additions & 11 deletions ...actRemoveUnusedParametersAndValuesDiagnosticAnalyzer.SymbolStartAnalyzer.BlockAnalyzer.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -342,17 +342,6 @@ private bool ShouldAnalyze(IOperation operationBlock, ISymbol owningSymbol, ref
case IConditionalOperation conditional when conditional.IsRef:
case ISimpleAssignmentOperation assignment when assignment.IsRef:
return false;

default:
// Workaround for https://github.com/dotnet/roslyn/issues/32100
// Bail out in presence of OperationKind.None - not implemented IOperation.
if (operation.Kind == OperationKind.None)
{
hasOperationNoneDescendant = true;
return false;
}

break;
}
}

Expand Down