diff options
author | martinboehme <mboehme@google.com> | 2024-03-28 16:05:11 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-03-28 16:05:11 +0100 |
commit | ae280281ce9f14f413ced0e44158a6fd41a98243 (patch) | |
tree | 0abb50bca433d67563afec91c912a9dc8f2a1a06 /llvm/lib/CodeGen/MachineCopyPropagation.cpp | |
parent | d3aa92ed142409266ebcc9cbc20e5f2c2d0209c0 (diff) | |
download | llvm-ae280281ce9f14f413ced0e44158a6fd41a98243.zip llvm-ae280281ce9f14f413ced0e44158a6fd41a98243.tar.gz llvm-ae280281ce9f14f413ced0e44158a6fd41a98243.tar.bz2 |
[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.
Diffstat (limited to 'llvm/lib/CodeGen/MachineCopyPropagation.cpp')
0 files changed, 0 insertions, 0 deletions