[libcxx-commits] [PATCH] D60480: [WIP] integration of pstl into libc++

Wed Apr 10 10:12:40 PDT 2019

rodgert added a comment.

In D60480#1461555 <https://reviews.llvm.org/D60480#1461555>, @jfb wrote:

> In D60480#1460733 <https://reviews.llvm.org/D60480#1460733>, @EricWF wrote:
>
> > In D60480#1460729 <https://reviews.llvm.org/D60480#1460729>, @rodgert wrote:
> >
> > > Not sure what is up with phabricator, but it won't let me respond inline to EricWF, specifically -
> > >
> > > __FIRST_MOVER_ADVANTAGE
> > >
> > > libc++ and libstdc++ have different 'uglification' protocols. As I said to mclow early on in this process, If I'm the one that has to do the grunt work of *all* of the uglification (very much has been case, BTW), it's going to follow libstdc++ convention as much as is possible.
> >
> >
> > libc++ code should follow libc++ conventions.
>
>
> Just to be clear: PSTL is neither libc++ nor libstdc++. Louis kinda said so above, and Tom is making that point too, but I want to reiterate it. It's overall a silly bikeshedding point, but it's critical to keep everyone happy. PSTL isn't more "ours" than "theirs" (or rather, it's "ours" in that we're all in the same C++ team). This point was critical in getting PSTL to be a shared resource in the first place, and I don't want to walk back this commitment.
>
> As Tom mentions above, we've talked about having tooling to massage PSTL to libc++'s and libstdc++'s liking on integration. Without volunteers to write said tooling, we should just accept slight ache when integrating PSTL, as we see here when integrating it into libc++.

The process of applying this kind of change is very error prone. I still have a patch coming that fixes a few cases I missed. That's the bigger argument IMO for tooling than the specific format.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60480