findtoken.h: make sure code is being matchcompiled #6641
Conversation
|
Clang 18 This should help with https://trac.cppcheck.net/ticket/12271. Detecting match calls in headers is tracked in https://trac.cppcheck.net/ticket/11541. This is obviously extremely horrible and needs to be done differently. Because templates are involved I could not come up with something better for now - but because of the sizable impact I published it anyways. |
|
The example from https://trac.cppcheck.net/ticket/10765#comment:4. Clang 17 |
|
@pfultz2 Care to have a look at this? Thanks! |
|
The example from https://trac.cppcheck.net/ticket/10765#comment:4. Clang 17 This makes a lot of difference and we really need to figure out how to get this change in properly. |
| @@ -92,7 +96,8 @@ bool findTokensSkipDeadCodeImpl(const Library& library, | |||
| if (found(tok)) | |||
| return true; | |||
| } | |||
| if (Token::Match(tok, "if|for|while (") && Token::simpleMatch(tok->linkAt(1), ") {")) { | |||
| //if (Token::Match(tok, "if|for|while (") && Token::simpleMatch(tok->linkAt(1), ") {")) { | |||
| if (findTokensSkipDeadCodeImplMatch_1(tok)) { | |||
There was a problem hiding this comment.
Why cant the match compiler be updated to automatically generate this? This seems very problematic.
There was a problem hiding this comment.
Seems obvious in hindsight. But thinking about it I think there might be problems.
That would cause the matchcompiler.h include to spill which seems undesired. Same with the match functions. The latter will probably cause conflicts in other matchcompiled files which include this.
Can check thought if if it would work if we also process header files. Would be a better approach - albeit I would prefer if it only were temporary.
There was a problem hiding this comment.
That would cause the matchcompiler.h include to spill which seems undesired
What do you mean spill? There is a header guard.
Same with the match functions. The latter will probably cause conflicts in other matchcompiled files which include this.
I thought each function is appended a unique number.
There was a problem hiding this comment.
That would cause the matchcompiler.h include to spill which seems undesired
What do you mean spill? There is a header guard.
I mean that it will be includes in all files including this even when not necessary. It is just not clean.
Same with the match functions. The latter will probably cause conflicts in other matchcompiled files which include this.
I thought each function is appended a unique number.
I am not sure if that is unique globally or locally. The first is unnecessary since we only generate functions within source files. But will immediately come up if I try to include the headers.
There was a problem hiding this comment.
Okay. I just remembered the main issue.
The files need to be matchcompiled thus you need to store the modified files and build those. But if you do that with headers you also need to inject an additional header path in release builds and you two headers of the same name which might also cause issues.
So it is not just include the *.h in the matchcompiler.
No description provided.