[llvm-dev] Should we split llvm Support and ADT?

[Zachary Turner via llvm-dev]

Re-writing StringRef / ArrayRef etc to use the exact same API is a good
idea long term, but there's a lot of ugly messy details that need to be
dealt with.  There's thousands of uses of take_front / drop_front, etc that
have to be converted.  Then there's some methods that aren't in string_view
at all, like consume_integer(), consume_front(), etc that would have to be
raised up to global functions in StringExtras.  All of this can certainly
be done, but it's going to be a *ton* of churn and hours spent to get it
all STL-ified.

Do you consider this a blocker for doing such a split?  Would it make sense
to do it incrementally where we first just move StringRef et all wholesale,
and then incrementally work to STL-ify the interface?

On Wed, Jul 5, 2017 at 5:01 PM Chris Lattner <clattner at nondot.org> wrote:

> Yes, that proposal makes sense to me: the split would be between things
> that *are* known to be subsumed into later versions of C++, and therefore
> are a compatibility library.
>
> What do you think about this as an implementation approach:
>
>  - Rewrite StringRef (et al) to use the exact same APIs as
> std::string_view.  Keep the StringRef name for now.
>  - When cmake detects that C++’17 mode is supported, the build would set a
> -D flag.
>  - StringRef.h would just include the C++’17 header and typedef StringRef
> to that type.
>  - When we start requiring C++’17, someone can
> “StringRef”->RAUW(“std::string_view”) and nuke the header.
>
> This allows us to have a clean path out of these custom types, and makes
> it very clear that these headers are compatibility shims that go away in
> the future.  It also makes it clear what the division is.
>
> -Chris
>
>
>
> On Jul 5, 2017, at 10:38 AM, Zachary Turner <zturner at google.com> wrote:
>
> So, here is an example of where I think a split would be really helpful.
>
> https://reviews.llvm.org/D34667
>
> This code would benefit vastly even from just being able to use StringRef
> and ArrayRef.  We have other cases as well where we export some code that
> cannot depend on the rest of LLVM.
>
> Thinking about it some, StringRef, ArrayRef, and various other things like
> STLExtras and iterator.h basically can be summarized as "things that are
> either already already planned for, or wouldn't be entirely out of place in
> the STL itself".  For example, StringRef is std::string_view.  ArrayRef is
> std::array_view.  iterator_facade_base is a better version of
> std::iterator.
>
> So I would drop my suggestion to split the libraries in such a way that it
> might benefit TableGen, and instead re-word my suggestion to include only
> classes such as StringRef, ArrayRef, and other STL-like utilities that can
> benefit utilities like our demangler etc that cannot depend on the rest of
> LLVM.  If and when we ever require C++17 for building LLVM (a long ways
> away, obviously, but we might as well be forward thinking), we would
> certainly be able to use std::string_view and std::array_view in the
> demangler.  So splitting things in a way such as this makes long term sense
> IMO.
>
> On Sun, Jun 4, 2017 at 10:50 AM Zachary Turner <zturner at google.com> wrote:
>
>> Fair enough, i sort of regret mentioning that specific method of
>> splitting originally.
>>
>> For the record, i think any splitting should make sense on its own merit
>> without considering tablegen, and hopefully the end result of "tablegen
>> eventually depends on less stuff" would happen naturally
>> On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org>
>> wrote:
>>
>>>
>>> > On May 26, 2017, at 5:47 PM, Zachary Turner via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>> >
>>> > Changing a header file somewhere and having to spend 10 minutes
>>> waiting for a build leads to a lot of wasted developer time.
>>> >
>>> > The real culprit here is tablegen.  Can we split support and ADT into
>>> two - the parts that tablegen depends on and the parts that it doesn’t?
>>>
>>> In all the comments downthread, I think there is one thing that hasn't
>>> been mentioned: doing a split like this makes tblgen evolution more
>>> difficult.  If libsupport was split into “used by tblgen” and “not used by
>>> tblgen” sections, and then a new tblgen feature needs to use other parts of
>>> libsupport, they’d have to be moved into the “used by tblgen” directory.
>>>
>>> Splitting libsupport as a whole out into its own llvm subproject has
>>> come up many times though, and does make a lot of sense.
>>>
>>> -Chris
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/5538bc08/attachment.html>