Added a check for converting `BOOST_FOREACH(..., ...)` loops to use the new range-based loops in C++11.
This check have some limitations, see documentation for details.
Please specify type explicitly here.
Please add isLanguageVersionSupported.
Please synchronize this statement with statement in Release Notes.
It will be good idea to move it to separate code block and add something like from and to. See modernize checks as example. Same for other examples.
Please separate with newline and follow 80 character limit. Also closing quote for Null-terminated strings is missing.
I am wondering if this check is better placed in the modernize module?
#include <memory> for std::make_unique<>
Can this be const IdentifierInfo *?
Can't you just chain this with the previous statement?
Check->diag(...) << MacroName << FixItHint::CreateReplacement(...);
It would be better to detect known failure cases in the matcher and not issue a fixit but perhaps issue a diagnostic.
Can't you detect this in the matcher and not issue a fixit in that case?
Why define this (and foreach_r_) if you don't have any tests around it?
Do you intend to support a conversion for the reverse iteration?
Generic code is a good practize, but i vote against the modernize-foreach-to-range-for check. My arguments:
-Not everyone uses boost and not everyone agrees to see "boost checks" in the already large modernize section. In the future, there will be a lot of these checks, not only BOOST_FOREACH. This is for example Boost Assign, Boost Static Assert, Boost Format, and so on, you can go on and on.
-All the same as above can be said about Qt.
I vote against the "modernize" section for this check. See arguments above.
I do not understand how I can determine type of expression list_int (for example) at the preprocessing stage. This trick was not found in any of the existing checks.
Yes, i can just parse the string token char c into mini AST and then determine if this is a variable declaration.
Now that this is chained, you might need to clang-format on it again.
Probably best to just clang-format the whole file before you submit.
This is an implicit conversion from unsigned to bool,
However, my bigger question is what happens when someone
I looked at the header for LangOptions and it isn't clear whether
Ah, yes, ugh. I forgot that this is all done by looking at macros.
We really need a bit of infrastructure in clang-tidy to associate macro
I suppose you could match for loops and try to correlate them to
When you specify a standard on the command-line, the front end
Unfortunately, example does not correspond to the real BOOST_FOREACH, the tests do not reveal real problems. Will have to redo. I will come back to this patch in the future