Previously, type aliases were not handled (and resulted in an assertion
firing). This patch generalizes the model to consider aliases everywhere (a
previous patch already considered aliases for optional-returning functions).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp | ||
---|---|---|
2217 | Let's replace "check"/"checker" with "model" here and in the commit message. |
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.
clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp | ||
---|---|---|
2217 | Thanks, good point! |
Let's replace "check"/"checker" with "model" here and in the commit message.