Hello,

I am starting to use fpprofiler. Because I did not know what parameters should be sent to fpc, I decided to use fppinsert. At least one type of "instrumented" code fails to compile:
// some code { some comment }
is wrongly changed into
{ some code { some comment } }
which does not compile.

AFAICS the issue comes from the fact that PScanner only has the tkComment type, so that when fppinsert tries to rebuild the code, it has no way to know if it should use '//' or '{ }'.

Of course, I can't simply replace tkComment with 2 new distinct types, there is probably some other code somewhere, not even in the Lazarus repository, which uses the current set of token types.

I see at least 3 ways to solve my issue
1 - change fppinsert so that if it finds a bracket in the token, it should use '//' - I don't like much this solution
2 - use a flag in TPascalScanner (something like CommentType) allowing to know the type of comment if needed
3 - add 2 types tkCommentSlash and tkCommentBrackets into TToken plus an option to TPOptions so that the calling code could choose to use the simple tkComment or the more specific tkCommentSlash and tkCommentBrackets

I like the third method best, but I may be missing some drawbacks in these options, so what would be the preferred way to do it? Maybe a fourth idea?

Note: In FPC default $mode FPC and Lazarus default $mode ObjFPC nested comments are allowed. It is not allowed in $mode Delphi.

Mattias

2014-11-20 23:51 GMT+01:00 Mattias Gaertner :

Ah, the fourth way I wrote about :-) Yes, I could try this. but I am a bit anxious at the idea of switching mode now. Couldn't there be code which would still compile but with different results, thus creating unexpected bugs? Oh well, I could try. I have enough test cases to be reasonably sure.

So I am less anxious to change something in the scanner, but wouldn't something like what I suggested still be an improvement?

I guess yes. Although it is unlikely, because mode ObjFPC is usually more strict than mode Delphi.

Oh well, I could try. I have enough test cases to be reasonably sure. So I am less anxious to change something in the scanner, but wouldn't something like what I suggested still be an improvement?

I'm not familiar with the fpprofiler code, so I can't help you here.

Mattias

2014-11-21 0:58 GMT+01:00 Mattias Gaertner :

Thanks for trying :-) I thought that PScanner was outside of fpprofiler, but I just saw that it is actually part of fpprofiler, so I should feel free to implement the modifications I want, provided of course that I don't lose any functionality.