Oliver Stöneberg

In my limited local tests I did not see any measurable performance impact. So posting to see if it has any effect in the CI.

The `__GLIBC__` check only worked because of the ``. The `backtrace()` function is not available on all platforms but I have not figured out how to properly check for it....

With the current changes there is at 11% increase in `Tokenizer::simplifyTypedefCpp()`: ``` 633,270,864 ( 1.00%) build/tokenize.cpp:Tokenizer::simplifyTypedefCpp() [/home/runner/work/cppcheck/cppcheck/cppcheck] ``` ``` 704,783,980 ( 1.11%) build/tokenize.cpp:Tokenizer::simplifyTypedefCpp() [/home/runner/work/cppcheck/cppcheck/cppcheck] ``` But that still doesn't account...

#7772 addresses part of the regression. The rest seems mostly stemming from the default parameters for `Token::insertToken()`.

#7813 added more mitigations for the regressions from this change. But I still see a minor regression I need to look into.

The remaining regression just seems to be related to slight differences in the determined Ir count for very hot calls. I see no increase in calls.

> I think we had `emptyString` for performance reasons.. so how much has it slowed down? If you read my comments above you will see that I addressed the regressions...

This change might be problematic because it is obviously requires a test but so far there are *no* tests at all utilizing includes (see #261 for a related discussion). This...

This matches the behavior of Cppcheck.

I was getting to those hopefully soon. As you can see the existing PR was approved/merged just today. And I just posted my own follow-up earlier. I am also not...