Replace legacy function call patterns

[matter123]

Many issues such is #79, #76, #51, #50, #43, #26, #18, #17, #2? require changes to the patterns that tag function calls and declarations. These patterns are very long hard to maintain strings. This makes resolving these issue more work than it could be.

[jeff-hykin]

Whenever this does get upgraded hopefully we can have it match the general groups of:
return-type-area name parameter-area qualifier/specifier-area body-area

[matter123]

The following lines are patterns relating to functions that are still strings

Converted	line	name	example match
☑️	1201	meta.function.destructor	Foo::~Foo(
☑️	1224	meta.function.destructor.prototype	Foo::~Foo(
☑️	1561	meta.function-call	foo(
☑️	1572	meta.function.constructor	Foo::Foo(
☑️	1598	meta.function.constructor.initializer-list	Foo::Foo({
☑️	1789	c_function_call	foo(
☑️	2946	meta.function	foo(
☑️	3065	entity.name.function	foo(
☑️	3126	meta.function.definition.parameters	foo(

There is still no way of doing back references, correct? If so that blocks converting 1201, 1224, 1572, and 1598

1561, 1789, 2946, and 3065 all are similar but have slightly different exclusions, for instance reinterpret_cast<std::size_t>(__type_name) matches 1561 to be markes as meta.function-call but not the others.

[matter123]

@jeff-hykin What is the purpose of :function_definition?

[jeff-hykin]

I think it's supposed to capture the function name + parameter meta, but I'm not sure if it's actually accomplishing its goal.

It should probably be redone, along with all of the other function stuff.

Hopefully we can shrink everything down to 2 main patterns: function calls and function definitions

[matter123]

Function declarations might need to be merged with #71. (see https://godbolt.org/z/lDsYnh). That is probably rare enough that if they are not merged, not too much code would be incorrect.

[matter123]

Should special member functions like Foo::Foo(const Foo &other) receive any special tagging over normal constructors/operator overloads?

[jeff-hykin]

I guess we can tag normal constructors as .inline and then Foo::Foo as .out-of-line? There is probably a better C++ term for out of line things.

[matter123]

My question was should the copy constructor receive a more specific scope like entity.name.function.constructor.copy or just entity.name.function.constructor ?

[jeff-hykin]

If you have a pattern for it, or want to do it for yourself I don't see any harm. I doubt hardly anyone will use it though, so I wouldn't be worried about putting any work into it.

[matter123]

I'll probably put in an hour or two on it after this is resolved. I have quite a few special member functions. It would be nice if they were bold.

[jeff-hykin]

That's true, it might be nice to have a entity.name.function.special super class, and then put everything under them. I guess most all of them are constructors though so maybe entity.name.function.special isn't needed

[matter123]

I was thinking entity.name.function.constructor.special.{default,copy,move} and entity.name.function.special.{copy,move}

[jeff-hykin]

I think if there is a entity.name.function.special for the {copy,move} then the others {default,copy,move} should probably be entity.name.function.special.constructor.

It will be changing existing theme-scopes, but I think it would be more consistent/helpful overall.

[matter123]

Yeah that looks like a better name. entity.name.function.destructor should probably become entity.nane.function.special.destructor then.

[matter123]

The default constructor could be tagged as both entity.name.function.constructor.cpp entity.name.function.special.constructor.default. That would allow for consistent theming of both constructors and special member function with a single scope each, as well as preserving compatibility with existing scopes.

[jeff-hykin]

👍Thats a great idea

[jeff-hykin]

reminder to self: the operator overloads, constructor, and destructor still need to be updated

[jeff-hykin]

All function definitions are updated! 🎉