Details
-
Bug
-
Resolution: Incomplete
-
Not Evaluated
-
None
-
Qt Creator 4.14.0, Qt Creator 6.0.2
-
None
-
Windows 10 64-bit, observed in Creator 4.14.x and 6.0.2, MinGW 8.1.0 64-bit
Description
When statements that are not function type declarations look like function type declarations, the parser gets confused. These are statements of the form:
identifier1 ( identifier2 ) ( parameters? ) ;
Here are three examples (many more can be constructed). Given the following definitions (complete example source attached):
constexpr int SomeValue = 0; struct SomeClass { explicit SomeClass (int) { } void operator () (int=0) { } }; enum SomeEnum { ValueA, ValueB, ValueC, ValueD };
Example 1 shows this popping up when invoking a closure:
void example1 () { auto closure = [] (int) { return [] () { }; }; closure(SomeValue)(); // <-- here } |
The parser then believes SomeValue is a function type (no parameters, return type "closure").
Also note that "SomeValue" and "closure" are underlined with the "unused" marker. Similar behavior occurs in the rest of the examples as well.
Example 2 shows this with a class constructor followed by an invocation of a parentheses operator:
void example2 () {
SomeClass(SomeValue)();
}
|
Example 3 is a clearer example of the effect it has on syntax highlighting, and also demonstrates misparsing a parameter list:
void example3 (SomeEnum x) { switch (x) { case ValueA: case ValueB: case ValueC: case ValueD: ; } SomeClass(ValueB)(ValueD); } |
The parser treats "ValueB" as a function that takes a "ValueD" and returns a "SomeClass", and fails to color "ValueB" in the preceding switch statement. Additionally, when the cursor is positioned on ValueB, the little gray reference highlighter does not appear in the enum value list itself, showing that the association between "ValueB" and the enum has been lost:
And a Bonus Example shows the parser treating it as a function type with two overloads:
void bonus () { auto closure = [] (int) { return [] () { }; }; closure(SomeValue)(); SomeClass(SomeValue)(); } |