Hi Peter,

I like the changes you’ve made! I’ve noticed two things, though:

• I think that only warnings are printed, but errors are not (this will require just updating the isWarningRegexp regexp, or adding some other regexp that will cause errors printing without any checking).
• The current implementation filters even parts of the output that should be printed as a part of a warning, for example these ” instantiated from…” traces and some other lines. I’m fine with that (actually I’ve been filtering all of them, too), so if you’re ok with that too, then this is no longer a problem (we can remove the Solve the problem with ‘instantiated from here’ and ‘when initialized here etc. problem)

As for your lastest post:

I was thinking, maybe we do not need to match subsequent lines! We could just as well filter the individual warnings. For example, the following two warnings be filtered separately just fine (as you had done it, I’ve only modified the comments).
[snip]

Yes - actually these two kind of lines are now filtered no matter if they’re in the warning list or not because they’re dropped immediately (they don’t match the isWarningRegexp). This corresponds with the second bullet from the list above in this post.

The multi-line match pattern which you had before can be substituted with the simpler single-line regexps:

.*‘Protocols::BitTorrent::Torrents::FileInfo::.*’ should be initialized in the member initialization list

.*‘Protocols::BitTorrent::Torrents::Torrent::PrivateData::.*’ should be initialized in the member initialization list

Great, this simplifies it a lot!

Are there any other cases where you think multi-line match patterns would be useful? If not, I’d suggest that we drop support for them.

Hmm, I can’t think of any right now - I first thought that they will be needed in such cases, but as we can simplify these regexps, maybe we really could drop the support for them (also the script will become more simple).

Regards,

Petr