extracted ValueFlow::Value to vfvalue.{cpp|h}

[firewave]

No description provided.

[firewave]

Those helper structs in valueflow.h only had single users so I moved them to the appropriate scopes.

If we need those in more places we should probably add those to utils.h since it is generic code. I checked for potential duplicates but there were none.

[firewave]

@pfultz2 I am also looking at splitting the ValueFlow analysis i.e. ValueFlow::setValues() from the other code in valueflow.cpp.

It seems like most of the code related to the various steps is not shared at all. So I am wondering if it would be feasible to put these steps into separate modular files like vfnumber.h, 'vfstring.h' etc (or vfanumber). Shared code which is not yet exposed I would leave in the monolithic file for now but put in an internal namespace.

That approach would allow us to make this refactoring incremental and we don't need one big commit. That would also help with preventing/easing with potential conflicts in local branches and existing PRs.

@danmar I would also prefer to add an underscore to the file names though but we have not been doing that so far.

There's also some minor quibbles this exposed which I would clean up anyways.

[pfultz2]

I think it would be better to put valueflow under a subdirectory. And then include it with #include "valueflow/value.h", and the cpp file would be under lib/valueflow/valuecpp. That would match the namespacing for this class.

It seems like most of the code related to the various steps is not shared at all. So I am wondering if it would be feasible to put these steps into separate modular files like vfnumber.h, 'vfstring.h' etc (or vfanumber).

The same here, each pass would be under lib/valueflow/ directory. The issue I see with this is some passes need to construct the analyzer directly, so we should probably add a new valueFlowForward function.

That is my personal opinion. I dont know what @danmar thinks about it.

[pfultz2]

I am also looking at splitting the ValueFlow analysis i.e. ValueFlow::setValues() from the other code in valueflow.cpp.

Yea I would like to move the ConditionHandler to a separate file as well.

[firewave]

I think it would be better to put valueflow under a subdirectory. And then include it with #include "valueflow/value.h", and the cpp file would be under lib/valueflow/valuecpp. That would match the namespacing for this class.

I thought about that as well.

Yea I would like to move the ConditionHandler to a separate file as well.

That would fall under "shared code" i.e. internal stuff. That could probably go into several separate files as suggested.

I think we should decide what folder structure/naming is acceptable and then I will start prototyping with some low-hanging stuff.

[danmar]

I think it would be better to put valueflow under a subdirectory. And then include it with #include "valueflow/value.h", and the cpp file would be under lib/valueflow/valuecpp. That would match the namespacing for this class.

It's acceptable to me. I don't have a strong opinion. One opinion I do have is to keep a source file and its header in the same folder.

[firewave]

It's acceptable to me. I don't have a strong opinion. One opinion I do have is to keep a source file and its header in the same folder.

Great!

This can be merged anyways and I will prepare a PR with the first refactoring soon.

[firewave]

Will be made ready to merge after #4652 goes in.