vsavchenko marked an inline comment as done. vsavchenko added inline comments.
================ Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:467-470 +/// Available representations for the arguments are: +/// * RangeSet +/// * Optional<RangeSet> +/// * RangeSet * ---------------- xazax.hun wrote: > NoQ wrote: > > Why do we have these representations in the first place? > > > > It sounds like you're treating null pointers / empty optionals equivalently > > to full ranges (i.e., intersecting with them has no effect). How hard would > > it be to simply construct an actual full range in all the places in which > > we currently have empty optionals? > +1 > > I also find this confusing. Should I interpret a None as a full or empty > range? Does this depend on the context or a general rule? Is there any reason > we need to handle nullable pointers or could we actually make call sites more > uniform to get rid of some of the complexity here? > It sounds like you're treating null pointers / empty optionals equivalently > to full ranges (i.e., intersecting with them has no effect) It is not actually true. Empty optionals is the information that "this range information is not available for this symbol". It is true that intersecting with them has no effect, but they are semantically different in other aspects. Currently solver RELIES on the information that whether the range is available or not (see my previous comment), and we simply couldn't get rid of this behavior as part of NFC. > How hard would it be to simply construct an actual full range in all the > places in which we currently have empty optionals? It is not hard architecturally, but it WILL make the change functional and possibly impact the performance. > Should I interpret a None as a full or empty range? Neither of those. That is the problem right now, that we rely on different sources of information for the ranges and behave differently depending on whether one piece of information is available or not. > Does this depend on the context or a general rule? Semantics are always the same - this info is not available. > Is there any reason we need to handle nullable pointers? `State->get<XYZ>(abc)` returns a nullable pointer meaning optional object, it is hard to avoid it especially because we currently behave very differently when this information is not available. > ...could we actually make call sites more uniform to get rid of some of the > complexity here? Yes we can, but later on. See the explanations above and in my other comment. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82381/new/ https://reviews.llvm.org/D82381 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
