This is an archive of the discontinued LLVM Phabricator instance.

[clang][dataflow] Modify `optional` model to handle type aliases.
ClosedPublic

Authored by ymandel on Jun 3 2022, 9:23 AM.

Details

Summary

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).

Diff Detail

Event Timeline

ymandel created this revision.Jun 3 2022, 9:23 AM
ymandel requested review of this revision.Jun 3 2022, 9:23 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 3 2022, 9:23 AM
sgatev accepted this revision.Jun 3 2022, 9:31 AM
sgatev added inline comments.
clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
2217

Let's replace "check"/"checker" with "model" here and in the commit message.

This revision is now accepted and ready to land.Jun 3 2022, 9:31 AM
ymandel updated this revision to Diff 434048.Jun 3 2022, 9:38 AM
ymandel marked an inline comment as done.

address comments

ymandel retitled this revision from [clang][dataflow] Modify optional-checker to handle type aliases. to [clang][dataflow] Modify `optional` model to handle type aliases..Jun 3 2022, 9:39 AM
ymandel edited the summary of this revision. (Show Details)
xazax.hun accepted this revision.Jun 3 2022, 9:40 AM

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.

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!

This revision was landed with ongoing or failed builds.Jun 3 2022, 12:01 PM
This revision was automatically updated to reflect the committed changes.