-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reduced Tokenizer::isCPP()
usage / SymbolDatabase: removed mIsCpp
and isCPP()
#5725
Conversation
Tokenizer::isCPP()
Tokenizer::isCPP()
usage
This might also speed up processing C code a bit as we previously forcefully used the C++ handling where it might not have been appropriate. We should merge this after the next release so the impact of the changes might be visible instead of getting lost in months of accumulated differences. |
The remaining usages which could be removed is in conjunction with types that wrap a token - and those are sparse. I also think we could switch from |
6944e25
to
74fdbad
Compare
The tests which failed were added in ff9c04d. Looking at what they were testing for I wonder if these failures might be somewhat related to some regressions which occurred in 2.6: |
Further cleanups revealed potential issues/cases with undetermined standards. Those need to be resolved beforehand. Unfortunately that existing handling is quite awkward (surprise) so a fix is not straight forward and I currently can't wrap around it... It potentially might also require some other in-progress stuff to land first... |
74fdbad
to
cb3a387
Compare
Requires #5853 to be merged first. |
c488af5
to
e81a560
Compare
e81a560
to
c725400
Compare
947fb7a
to
cc41b98
Compare
lib/symboldatabase.cpp
Outdated
@@ -53,7 +53,7 @@ | |||
//--------------------------------------------------------------------------- | |||
|
|||
SymbolDatabase::SymbolDatabase(Tokenizer& tokenizer, const Settings& settings, ErrorLogger* errorLogger) | |||
: mTokenizer(tokenizer), mSettings(settings), mErrorLogger(errorLogger), mIsCpp(mTokenizer.isCPP()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this could have been left in to avoid the repeated calls on the tokens but the language had not been determined at this point yet so this caused assertions in the unit tests.
I also think it is cleaner to have one less place which provides this information.
Tokenizer::isCPP()
usageTokenizer::isCPP()
usage and some additional cleanups related to it
Tokenizer::isCPP()
usage and some additional cleanups related to itTokenizer::isCPP()
usage / SymbolDatabase: removed mIsCpp
and isCPP()
c7d6290
to
80a2077
Compare
c72a06b
to
2218041
Compare
…plicit-constructor` clang-tidy warning
…` clang-tidy and `functionStatic` selfcheck warning
Each
Token
(should) be connected to aTokenList
.Tokenizer
just encapsulates that so we have no need to check theTokenizer
but can simply ask theToken
.Also if we have function calls we pass in a flag to tell it if it is C/C++ we can get rid of that flag and simply ask the
Token
. In several cases we were only passing that flag to be used in some underlying calls making it completely unnecessary in the top call.