Do you handle access specifier?

[marehr]

I see in reductions that code like

class test : private bar
{
public:
  statement1;
  statement2;
};

will often be collapsed to

class test : private bar
{
public: statement1;
statement2;
};

The problem is that the statement1 line could be removed, but will trigger a build error because statement2 isn't accessible any more.

I would expect that all access specifier will be removed at a pretty early stage as they most often shouldn't matter.

That means class should be replaced by struct and any access specifier should be removed from a class.

/*class*/ struct test : /*private*/ public bar
{
/*public:*/ statement1;
statement2;
};

[marxin]

Thank you for the report. I'm pretty sure there are passes that remove tokens (or group of tokens) and these should handle the removal of public:. About the replacement of class with struct, that's really not supported. I see it as a minor enhancement.

[marehr]

Interesting this is a transformation that I quite often have to do manually and is at least in our code basis (declaring non-pod types as class as described in the google style guide) a pretty common occurrence.

It is true that the token reduction step will remove those tokens eventually, but only if it has no "effect" on the "visibility". If a public: token is removed, it will most certainly change the visibility in our code basis and in the end will not be removed.

I also have some other common problems with C++20 and concepts where cvise is stuck at some point. But, if those things are only minor enhancement, I'm not sure if you are interested in them. I just wanted to let you know, that it would help me greatly if those steps would be automatic, too. As I pretty regularly use cvise :)

[marxin]

Interesting this is a transformation that I quite often have to do manually and is at least in our code basis (declaring non-pod types as class as described in the google style guide) a pretty common occurrence.

It is true that the token reduction step will remove those tokens eventually, but only if it has no "effect" on the "visibility". If a public: token is removed, it will most certainly change the visibility in our code basis and in the end will not be removed.

All right, I can take a look at what can be done. I would appreciate an example of an interestingness test and a test-case for it.

I also have some other common problems with C++20 and concepts where cvise is stuck at some point. But, if those things are only minor enhancement, I'm not sure if you are interested in them.

I'm definitely interested in these issues. Please show me some examples where it's stuck.

I just wanted to let you know, that it would help me greatly if those steps would be automatic, too. As I pretty regularly use cvise :)

Appreciate that, I'm happy for daily users of the tool!