[all-commits] [llvm/llvm-project] 5a1666: [clang][dataflow] Use `Strict` accessors in more p...

[martinboehme via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5a16665ed53500b7ee6703be3d5b9e0bca6f1c14
      https://github.com/llvm/llvm-project/commit/5a16665ed53500b7ee6703be3d5b9e0bca6f1c14
  Author: Martin Braenne <mboehme at google.com>
  Date:   2023-05-22 (Mon, 22 May 2023)

  Changed paths:
    M clang/lib/Analysis/FlowSensitive/Transfer.cpp

  Log Message:
  -----------
  [clang][dataflow] Use `Strict` accessors in more places in Transfer.cpp.

This patch handles the straightforward cases. Upcoming separate patches will handle the cases that are more subtle.

This patch is part of the ongoing migration to strict handling of value categories (see https://discourse.llvm.org/t/70086 for details).

Depends On D150653

Reviewed By: sammccall, ymandel, xazax.hun

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


  Commit: 8bc8fc65c9b20de6ffad63d7ce6734c145265cc2
      https://github.com/llvm/llvm-project/commit/8bc8fc65c9b20de6ffad63d7ce6734c145265cc2
  Author: Martin Braenne <mboehme at google.com>
  Date:   2023-05-22 (Mon, 22 May 2023)

  Changed paths:
    M clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp

  Log Message:
  -----------
  [clang][dataflow] Use `Strict` accessors in TypeErasedDataflowAnalysis.cpp.

This patch is part of the ongoing migration to strict handling of value categories (see https://discourse.llvm.org/t/70086 for details).

Depends On D150655

Reviewed By: sammccall, ymandel, xazax.hun

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


  Commit: 96b22e1c378a93a26cd8fc8051bfc7b90f65b665
      https://github.com/llvm/llvm-project/commit/96b22e1c378a93a26cd8fc8051bfc7b90f65b665
  Author: Martin Braenne <mboehme at google.com>
  Date:   2023-05-22 (Mon, 22 May 2023)

  Changed paths:
    M clang/unittests/Analysis/FlowSensitive/SignAnalysisTest.cpp

  Log Message:
  -----------
  [clang][dataflow] Use `Strict` accessors in SignAnalysisTest.cpp.

This patch is part of the ongoing migration to strict handling of value categories (see https://discourse.llvm.org/t/70086 for details).

Depends On D150656

Reviewed By: sammccall, ymandel, xazax.hun

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


  Commit: 3bc1ea5b0ac90e04e7b935a5d964613f8fbad4bf
      https://github.com/llvm/llvm-project/commit/3bc1ea5b0ac90e04e7b935a5d964613f8fbad4bf
  Author: Martin Braenne <mboehme at google.com>
  Date:   2023-05-22 (Mon, 22 May 2023)

  Changed paths:
    M clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
    M clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp

  Log Message:
  -----------
  [clang][dataflow] Fix a bug in handling of `operator->` for optional checker.

Prior to this patch, `operator->` was being handled like `operator*`: It was
associating a `Value` of type `T` with the expression result (where `T` is the
template argument of the `optional<T>`). This is correct for `operator*`, which
returns a reference (of some flavor) to `T`, so that the result of the
`CXXOperatorCallExpr` is a glvalue of type `T`. However, `operator*` returns a
`T*`, so the result of the `CXXOperatorCallExpr` is a prvalue `T*`, which should
therefore be associated with `PointerValue` that in turn refers to a `T`.

I noticed this issue while working on the migration to strict handling of
value categories (see https://discourse.llvm.org/t/70086). The current behavior
also seems problematic more generally because it's plausible that the framework
may at some point introduce behavior that assumes an `Expr` of pointer type is
always associated with a `PointerValue`.

As it turns out, this patch fixes an existing FIXME in the test
`OptionalValueInitialization`.

Depends On D150657

Reviewed By: ymandel

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


Compare: https://github.com/llvm/llvm-project/compare/0d95b20b63d7...3bc1ea5b0ac9