CPP scope migration

[AndreasArvidsson]

Checklist

• I have added tests
• [/] I have updated the docs and cheatsheet
• [/] I have not broken the cheatsheet

[pokey]

started making some tweaks in 2ce105d because I noticed some incorrect scopes but ran out of steam. see the new scope fixtures; some are wrong

[AndreasArvidsson]

Good call. I made some fixes, but there are still some work left to do that will have to wait until tomorrow.

[AndreasArvidsson]

@pokey I think this is ready now

[pokey]

Wow yeah getting these right requires work. I did a deep dive on class-like constructs (ie class, enum, struct, and union). I made sure those behave well for "type", "state", "class", "name", and "class name".

I ended up putting multiple scopes in a single file because otherwise the combinatorial explosion was pretty brutal. I know you are not a fan of that style, and I can see your case, but I'm not sure we should be dogmatic about it if it would result in dozens of files. Lmk what you think

Btw one advantage of putting multiple scopes in a single flie is that it can actually catch bugs. You had forgotten to anchor your semicolons to the statement they follow, so we had a bug where you would inadvertently treat two subsequent classes as a single class. Eg

struct aaa {};
struct bbb{};

Would result in one big class for both lines 😳. I was able to notice this because I had tests with multiple scopes, whereas it would not have been caught with a single scope

Anyways, merge if you're happy with my changes

[AndreasArvidsson]

Nicely done. In regards to anchoring the semicolon this is not something that we do in all places. If you search through the code base of scm files you find multiple places where we don't do this. Might of course be okay in those specific scenarios, but I do wonder if that is also an oversight?

[pokey]

Nicely done. In regards to anchoring the semicolon this is not something that we do in all places. If you search through the code base of scm files you find multiple places where we don't do this. Might of course be okay in those specific scenarios, but I do wonder if that is also an oversight?

It's a good question. It's possible it works in other places because of the way the hierarchy is. Eg the reason this fails is that the parser will create a series of statements and semicolons all as direct siblings. If other parse trees don't have this flat structure it should be fine. But agreed worth a grep to find examples and test them out at some point