This is an archive of the discontinued LLVM Phabricator instance.

[Analyzer] Moved RangeConstraintManager to header. NFC.
AbandonedPublic

Authored by mikhail.ramalho on Jun 25 2018, 1:07 PM.

Diff Detail

Repository
rC Clang

Event Timeline

george.karpenkov accepted this revision.Jun 26 2018, 5:43 PM

LGTM, I hope we can eventually merge the two.

This revision is now accepted and ready to land.Jun 26 2018, 5:43 PM
This revision was automatically updated to reflect the committed changes.
george.karpenkov reopened this revision.Jun 27 2018, 8:04 PM

After thinking about this change a bit longer, I think it does not make sense.

Albeit poorly named, the previous design had a purpose: RangedConstraintManager is a public interface, and RangeConstraintManager is a private implementation.
Exposing both in the header does not make sense.

For exposing the factory could you just move the factory and it's getter?
Another solution is just merging the two classes entirely, but that's more heavyweight, and would force exposing private functions in a header (but those could be just moved to static C functions).
@NoQ further comments?

include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
120

Adding this dump method resulted in a bot breakage on our side (during the linking process).
I'm not 100% sure why, but since this belongs in a separate review anyway, could we drop those lines?

This revision is now accepted and ready to land.Jun 27 2018, 8:04 PM
george.karpenkov requested changes to this revision.Jun 27 2018, 8:04 PM
This revision now requires changes to proceed.Jun 27 2018, 8:04 PM

After thinking about this change a bit longer, I think it does not make sense.

Albeit poorly named, the previous design had a purpose: RangedConstraintManager is a public interface, and RangeConstraintManager is a private implementation.
Exposing both in the header does not make sense.

For exposing the factory could you just move the factory and it's getter?
Another solution is just merging the two classes entirely, but that's more heavyweight, and would force exposing private functions in a header (but those could be just moved to static C functions).
@NoQ further comments?

Since we decided to go with the other approach in D48565, we don't actually need this patch anymore.

mikhail.ramalho abandoned this revision.Jun 28 2018, 1:29 PM

We won't need this patch anymore because we'll try another approach in D48565.