ymandel added a comment.
In D126972#3556230 <https://reviews.llvm.org/D126972#3556230>, @xazax.hun wrote:
> This patch looks good to me. On the other hand, I was wondering whether
> functions like this would be handled:
>
> pair<optional, optional> f();
> array<optional, 4> g();
> MyStructWithOptionals h();
>
> And so on. In general, I wonder if it is a better approach to be able to plug
> the optional creation function into the general value creation function of
> the engine. So whenever the engine encounters an optional type, it could
> create the corresponding value. It could do it lazily or eagerly, however it
> choses. And the user would no longer need to match all the possible ways an
> optional type can be mentioned somewhere.
Thanks! Good points. Those results won't be handled directly, but they will be
handled eventually, when accessed (via the various mechanisms that you've
highlighted). I think you're right that something needs to change -- we
shouldn't be trying to catch these cases, and perform the corresponding
initialization, at each point. Personally, I prefer a lazy approach (and have a
short proposal I hope to share soon), but eager or lazy there should be some
single code that plugs in and handles the types of interest to a model, rather
than the model explicitly "trapping" every point the author can remember to
insert initialization.
================
Comment at:
clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp:2217
+// Verifies that the check sees through aliases.
+TEST_P(UncheckedOptionalAccessTest, WithAlias) {
----------------
sgatev wrote:
> Let's replace "check"/"checker" with "model" here and in the commit message.
Thanks, good point!
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126972/new/
https://reviews.llvm.org/D126972
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
