simplecpp
simplecpp copied to clipboard
danmar
Issue# 168: Fix invalidHashHash exception on valid token.
you should probably check what tokens you get if you don't use ## also :
a = 1_y;
b = "x"_y;
How will this roll out into a release of cppcheck? I've just encountered this problem which for now I have inline suppressed.
I am anxious to merge this. I just want to know that it really works. As I wrote.. I believe @IOBYTE made some fix in Cppcheck for this C++ feature a while ago.. does this match that fix?
How is this output handled by Cppcheck? I believe that "x"_y shouldn't be treated as a string. What is the type set by Cppcheck? You can see that by using --debug --verbose and look in the AST output.
Sorry, I forgot about this. I'll try to look into it this weekend. Thanks for the pointers.
@bedw021 Has this fixed been merged into simplecpp? Any idea if it has then made its way into CppCheck? Thanks.
I have the feeling we have not got a fix in simplecpp yet. :-(
If anybody wants to take over and work on this .. I think that is possible.
@danmar @bedw021 Could this be merged into simplecpp so that CppCheck can be updated? We've got inline suppresion for CppCheck in our codebase due to this. Thanks.
@BillDenton feel free to finish this. the comment @bedw021 made on aug 15th sounds pretty promising to me.
On Aug 15th I wrote:
Should we go ahead with this to make it like how cppcheck processes it, or try operator"" {TokenB} ( {TokenA} ) which might give more meaningful output in cppcheck (although it still doesn't seem to get the return type from the function).?
I suggest the first option for now. We need to handle this better in cppcheck.
@BillDenton feel free to implement first option. Or if you prefer option 2 that is fine but then you'll need to tweak cppcheck also.
@BillDenton I don't know this feature very well. I have never used it myself. Could you write some minimal "compilable" example(s) that I can try out?
Ideally simplecpp should output the "proper" output. And then if that is not ideal for Cppcheck then we should fix Cppcheck.
Third time’s the charm? I also stumbled into a/the exception with macro + operator"" constructs so I guess a fix is still pending?
With a similar set of (naive) changes hacked into my local version (current from a few days ago) it looks plausible for simple test cases at least (“works for me”). I think there may be cases where B needs expanding but building test cases is always bit of a rabbit hole...
Are there similar tickets over on the cppcheck trac?
@patrickdowling sorry for late reply. yes it would be good to get this fixed finally. I am not sure if there is corresponding tickets in cppcheck. I don't think so.
@danmar No worries. So the I’ve somewhat brute forced things in this branch with some dangling todos and have a few simplecpp vs. g++ scenarios here. On the way I’ve realised how hazy I am on the details of macros/pasting so I'm open to corrections.
Perhaps it makes sense to roll in other ## related issues? E.g. as has been suggested it’d be nice to see what is not being pasted when it fails by extending struct invalidHashHash, but I'm also wary of scope creep 😀 Should I open a fresh PR and move the discussion there?
I'm also wary of scope creep
yes me too. And this has been open long enough already. I suggest you try to solve just a specific problem now and we can look at related issues later. I think your suggestion to extend invalidHashHash sounds good for instance.