[all-commits] [llvm/llvm-project] 58fe7f: [clang][dataflow] Add API to separate analysis fro...

[Sam Estep via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 58fe7f9683a020a880426a4d8d61b067b83a9380
      https://github.com/llvm/llvm-project/commit/58fe7f9683a020a880426a4d8d61b067b83a9380
  Author: Sam Estep <sam at samestep.com>
  Date:   2022-06-29 (Wed, 29 Jun 2022)

  Changed paths:
    M clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
    M clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
    M clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
    M clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
    M clang/unittests/Analysis/FlowSensitive/TestingSupport.h
    M clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp

  Log Message:
  -----------
  [clang][dataflow] Add API to separate analysis from diagnosis

This patch adds an optional `PostVisitStmt` parameter to the `runTypeErasedDataflowAnalysis` function, which does one more pass over all statements in the CFG after a fixpoint is reached. It then defines a `diagnose` method for the optional model in a new `UncheckedOptionalAccessDiagnosis` class, but only integrates that into the tests and not the actual optional check for `clang-tidy`. That will be done in a followup patch.

The primary motivation is to separate the implementation of the unchecked optional access check into two parts, to allow for further refactoring of just the model part later, while leaving the checking part alone. Currently there is duplication between the `transferUnwrapCall` and `diagnoseUnwrapCall` functions, but that will be dealt with in the followup.

Because diagnostics are now all gathered into one collection rather than being populated at each program point like when computing a fixpoint, this patch removes the usage of `Pair` and `UnorderedElementsAre` from the optional model tests, and instead modifies all their expectations to simply check the stringified set of diagnostics against a single string, either `"safe"` or some concatenation of `"unsafe: input.cc:y:x"`. This is not ideal as it loses any connection to the `/*[[check]]*/` annotations in the source strings, but it does still retain the source locations from the diagnostic strings themselves.

Reviewed By: sgatev, gribozavr2, xazax.hun

Differential Revision: https://reviews.llvm.org/D127898