[PATCH] D57115: [llvm] Remove dependency on <algorithm> [NFC]

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D57115#1368363 <https://reviews.llvm.org/D57115#1368363>, @mgrang wrote:

> In D57115#1368350 <https://reviews.llvm.org/D57115#1368350>, @dblaikie wrote:
>
> > In D57115#1368345 <https://reviews.llvm.org/D57115#1368345>, @mgrang wrote:
> >
> > > In D57115#1368335 <https://reviews.llvm.org/D57115#1368335>, @dblaikie wrote:
> > >
> > > > "mainly" used for std::sort might be true, but "only" used might be harder to prove - did you use any tooling to test that these inclusions weren't needed other than "this code still compiles" (which has the problem that the inclusion might be used, but also included indirectly from some other header - so removing it may still compile, but introduces an undesirable indirect dependency on an implementation detail of some other header)
> > >
> > >
> > > I ran ninja check-all and did not see any failures. I haven't changed the places where algorithm is needed (like for std::fill, etc) and which introduced compile errors. I have also not touched examples, unittests and util/unittest directories.
> >
> >
> > How did you identify these "I haven't changed the places where algorithm is needed (like for std::fill, etc)" places? By visual inspection of every file that's been touched?
>
>
> No, I removed the header from all files and then put back only where the compilation failed. I agree with your comment "removing it may still compile, but introduces an undesirable indirect dependency on an implementation detail of some other header".


Yeah, I don't think it's probably the best thing to commit a change like that for this header or any other (you can imagine how brittle the codebase might become if we did this for all headers)

>   I guess there is no foolproof way to rule out *any* possible use of the header?

There are some tools - IWYU was an old one that had some issues, but made some effort to get this right ( https://include-what-you-use.org/ ) and I don't know if any clang tools (clang-tidy or the like) have grown a better implementation of that functionality yet.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57115/new/

https://reviews.llvm.org/D57115