This is an archive of the discontinued LLVM Phabricator instance.

[clang][dataflow] Use `Strict` accessors in SignAnalysisTest.cpp.
ClosedPublic

Authored by mboehme on May 16 2023, 3:17 AM.

Details

Summary

This patch is part of the ongoing migration to strict handling of value categories (see https://discourse.llvm.org/t/70086 for details).

Depends On D150656

Diff Detail

Event Timeline

mboehme created this revision.May 16 2023, 3:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 16 2023, 3:17 AM
mboehme requested review of this revision.May 16 2023, 3:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 16 2023, 3:17 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
mboehme edited the summary of this revision. (Show Details)May 16 2023, 3:18 AM
mboehme added reviewers: sammccall, ymandel, xazax.hun.
sammccall accepted this revision.May 16 2023, 4:58 AM
sammccall added inline comments.
clang/unittests/Analysis/FlowSensitive/SignAnalysisTest.cpp
240

this seems to belong on Environment rather than here!

This revision is now accepted and ready to land.May 16 2023, 4:58 AM
mboehme updated this revision to Diff 522554.May 16 2023, 5:13 AM

Added a comment

mboehme added inline comments.May 16 2023, 5:21 AM
clang/unittests/Analysis/FlowSensitive/SignAnalysisTest.cpp
240

I've consciously kept this function local to this file for now because it has relatively complex semantics and I haven't seen any other places where these are required so far. I've added a comment noting that this should be moved if it turns out to be needed elsewhere.

I think that, as much as possible, the methods on Environment should be specific about the value category they operate on, because most of the time, it's known what the value category is, and I'd like to encourage users to use the most specific operation possible (because using more general operations breeds bugs).

ymandel accepted this revision.May 16 2023, 5:30 AM
sammccall added inline comments.May 16 2023, 6:24 AM
clang/unittests/Analysis/FlowSensitive/SignAnalysisTest.cpp
240

I think that, as much as possible, the methods on Environment should be specific about the value category they operate on

I agree, but don't think that's specific to Environment.
I think my favorite factoring of this would be to inline the if/else and move the branches to methods on environment

Value *Val = E->isGLValue() ? Env.getOrCreateLValue(*E) : Env.getOrCreateValue(*E);

but this is test code, it doesn't matter much, up to you.

xazax.hun accepted this revision.May 16 2023, 9:57 AM
xazax.hun added inline comments.
clang/unittests/Analysis/FlowSensitive/SignAnalysisTest.cpp
134

Wow, this is so much cleaner than before!

240

So, we could either make an API that forces users to think about value categories explicitly, or we could try to design an API where the users do not need to know about value categories at all. I think it might be worth exploring if the latter is possible without any major caveats, the simpler the APIs are the better. But this is for the future, not for this PR.

mboehme marked 2 inline comments as done.May 17 2023, 7:25 AM
mboehme added inline comments.
clang/unittests/Analysis/FlowSensitive/SignAnalysisTest.cpp
240

I think that, as much as possible, the methods on Environment should be specific about the value category they operate on

I agree, but don't think that's specific to Environment.
I think my favorite factoring of this would be to inline the if/else and move the branches to methods on environment

Value *Val = E->isGLValue() ? Env.getOrCreateLValue(*E) : Env.getOrCreateValue(*E);

I'm hesitant to do this because even getOrCreateValue() is an operation with relatively "loose" semantics. If anything, my sense is that operations like this should go in TestingSupport.h rather than Environment -- from what I've seen so far, these types of operations tend to occur mostly in tests, while the non-test code usually has more "rigid" semantics.

240

So, we could either make an API that forces users to think about value categories explicitly, or we could try to design an API where the users do not need to know about value categories at all. I think it might be worth exploring if the latter is possible without any major caveats, the simpler the APIs are the better. But this is for the future, not for this PR.

I'll keep this in mind, but I'll admit I have my doubts. The existing API can be seen as doing this (i.e. providing an API that does not require knowing about value categories), and it is actually more complex to use in many cases, and more error-prone. Fundamentally, I think if you're dealing with static analysis on the Clang AST you need to understand value categories to get the code right.

This revision was landed with ongoing or failed builds.May 21 2023, 11:51 PM
This revision was automatically updated to reflect the committed changes.
mboehme marked an inline comment as done.