[all-commits] [llvm/llvm-project] ae2802: [clang][dataflow] Fix for value constructor in cla...

martinboehme via All-commits all-commits at lists.llvm.org
Thu Mar 28 08:05:33 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ae280281ce9f14f413ced0e44158a6fd41a98243
      https://github.com/llvm/llvm-project/commit/ae280281ce9f14f413ced0e44158a6fd41a98243
  Author: martinboehme <mboehme at google.com>
  Date:   2024-03-28 (Thu, 28 Mar 2024)

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

  Log Message:
  -----------
  [clang][dataflow] Fix for value constructor in class derived from optional. (#86942)

The constructor `Derived(int)` in the newly added test
`ClassDerivedFromOptionalValueConstructor` is not a template, and this
used to
cause an assertion failure in `valueOrConversionHasValue()` because
`F.getTemplateSpecializationArgs()` returns null.

(This is modeled after the `MaybeAlign(Align Value)` constructor, which
similarly causes an assertion failure in the analysis when assigning an
`Align`
to a `MaybeAlign`.)

To fix this, we can simply look at the type of the destination type
which we're
constructing or assigning to (instead of the function template
argument), and
this not only fixes this specific case but actually simplifies the
implementation.

I've added some additional tests for the case of assigning to a nested
optional
because we didn't have coverage for these and I wanted to make sure I
didn't
break anything.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list