bug: Conversion operator definition not recognized as such

[emaxx-google]

Did you check existing issues?

• [x] I have read all the tree-sitter docs if it relates to using the parser
• [x] I have searched the existing issues of tree-sitter-cpp

Tree-Sitter CLI Version, if relevant (output of tree-sitter --version)

the latest used at https://tree-sitter.github.io/tree-sitter/7-playground.html

Describe the bug

A conversion operator is sometimes misinterpreted as a regular function with a weird (broken) return type, as opposed to operator_cast.

Steps To Reproduce/Bad Parse Tree

  function_definition [0, 0] - [2, 1]
    storage_class_specifier [0, 0] - [0, 6]
    type: qualified_identifier [0, 7] - [0, 18]
      scope: namespace_identifier [0, 7] - [0, 8]
      name: type_identifier [0, 10] - [0, 18]
    declarator: function_declarator [0, 19] - [0, 24]
      declarator: identifier [0, 19] - [0, 22]
      parameters: parameter_list [0, 22] - [0, 24]
    body: compound_statement [0, 25] - [2, 1]
      return_statement [1, 2] - [1, 12]
        number_literal [1, 9] - [1, 11]

Which is incorrect since it treats this as a function called int with the A::operator return type.

Expected Behavior/Parse Tree

Removing inline in this example results in a correct parsing:

  function_definition [0, 0] - [2, 1]
    declarator: qualified_identifier [0, 0] - [0, 17]
      scope: namespace_identifier [0, 0] - [0, 1]
      name: operator_cast [0, 3] - [0, 17]
        type: primitive_type [0, 12] - [0, 15]
        declarator: abstract_function_declarator [0, 15] - [0, 17]
          parameters: parameter_list [0, 15] - [0, 17]
    body: compound_statement [0, 18] - [2, 1]
      return_statement [1, 2] - [1, 12]
        number_literal [1, 9] - [1, 11]

Repro

inline A::operator int() {
  return 42;
}

[percontation]

I am running into this as well. Basically, conversion functions defined outside the class body are mis-parsed if there is something in the function_definition before the qualified_declarator, e.g. SOMETHINGHERE ClassPath::operator bool() { return true; }, where the "something" can be a [[attribute]]/__attribute__((...))/inline/virtual/constexpr/consteval or possibly more (explicit can also go here, but, that one is always parsed correctly).

Note: you can get the correct parse to appear via editing, i.e. inserting inline into source that already has the operator_cast node. So, I imagine that if the operator keyword was unable to be parsed as a type_identifier, that would fix the bug.

A related bug (or possibly the exact same bug, not sure) also happens inside a friend_declaration, e.g. class class X { friend Y::operator bool(); };.