removed `emptyString` and its remaining usage

[firewave]

[firewave]

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.

[firewave]

The __GLIBC__ check only worked because of the <string>. The backtrace() function is not available on all platforms but I have not figured out how to properly check for it. So just enable it unconditionally of that and wait for some feedback. We probably should split up these preprocessor checks and make them base on the feature/function we use.

[firewave]

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 for the total increase:

63,276,354,832 (100.0%)  PROGRAM TOTALS

63,413,640,429 (100.0%)  PROGRAM TOTALS

[firewave]

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

[firewave]

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

[firewave]

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.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[firewave]

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 it caused and that it hasn't slowed down.