build error on Building CXX object tools/clang/lib/StaticAnalyzer/Core/CMakeFiles/clangStaticAnalyzerCore.dir/SarifDiagnostics.cpp.o

Clang Frontend
1

from master branch

svn log -l 1

2

Hi Aaron,

Do you think you could take a look?
I still think it’s better to express such things as for loops.

Thanks,
George

3

Grady: Hmm, buildbots chewed through this just fine, even those on macOS with older compilers, and it does compile for me on a newer compiler as well.

Aaron: I don’t know if sys::path::const_iterator is an STL forward iterator; from the doxygen () it looks like it’s only an input iterator, which is not enough (it will be enough when we move to C++17). I guess we can always stuff a simple iterator loop in there and it should compile just fine; do you have any immediate ideas on how to preserve the expressiveness of std::for_each here?

4

Grady: Hmm, buildbots chewed through this just fine, even those on macOS with older compilers, and it does compile for me on a newer compiler as well.

Aaron: I don't know if sys::path::const_iterator is an STL forward iterator; from the doxygen (http://llvm.org/doxygen/classllvm_1_1sys_1_1path_1_1const__iterator.html) it looks like it's only an input iterator, which is not enough (it will be enough when we move to C++17). I guess we can always stuff a simple iterator loop in there and it should compile just fine; do you have any immediate ideas on how to preserve the expressiveness of std::for_each here?

Yeah, I think you're correct, this needs to be a forward iterator
rather than an input iterator. I think this will have to go back to
using a for loop for now. It's not ideal, but it at least fixes the
issue.

~Aaron

5

>
> Grady: Hmm, buildbots chewed through this just fine, even those on macOS with older compilers, and it does compile for me on a newer compiler as well.
>
> Aaron: I don't know if sys::path::const_iterator is an STL forward iterator; from the doxygen (http://llvm.org/doxygen/classllvm_1_1sys_1_1path_1_1const__iterator.html) it looks like it's only an input iterator, which is not enough (it will be enough when we move to C++17). I guess we can always stuff a simple iterator loop in there and it should compile just fine; do you have any immediate ideas on how to preserve the expressiveness of std::for_each here?

Yeah, I think you're correct, this needs to be a forward iterator
rather than an input iterator. I think this will have to go back to
using a for loop for now. It's not ideal, but it at least fixes the
issue.

I missed the fact that the problem was with std::next() and not
std::for_each(). I replaced the std::next() with a manual advancement
and commit in r346266.

~Aaron