https://bugs.kde.org/show_bug.cgi?id=468605
--- Comment #5 from Alessandro Carinelli <carinell.ialessandr...@gmail.com> --- Thanks for the help. Unfortunately both clang_getDiagnosticCategoryText and clang_getDiagnosticSpelling seem to return empty strings in this case (while in the case of a floating point literal with a leading '.' they are respectively "Parse Issue" and "expected expression"). I noticed that when reproducing the bug as soon as the '.' gets replaced with "->" an autocompletion suggestion pops up containing only the name of the struct and this makes sense with the single completion result provided by clang. Only after a while an error shows up saying "Expected unqualified-id". Is it possible that this lag is the reason why it looks like everything is fine with the arrow and the program proceeds with the substitution? I had an idea: after we get trimmedText we move backwards starting from the character right before the '.' checking every character until we find something different from a letter (upper or lowercase), an underscore or a digit, in this way we should find the first character in the identifier or literal that precedes the '.', if such first character is a digit we know that we are dealing with a floating point literal and skip the substitution. I tried it and it seems to work without noticeable performance issues. -- You are receiving this mail because: You are watching all bug changes.
