search for: array_view

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: > > >

...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 b...

...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 th...

...>>> 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 StringRe...

...tras 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 >>>>&g...

...to be fixed as well. How would we do with ArrayRef as function argument, built from an R-value? Sounds like a valid use-case to me. [Keane, Erich] Huh, I hadn't thought of that, but that definitely explains why the GSL version of "span" doesn't delete them. Also explains why the array_view paper doesn't mention this as well. I guess it is up to the user to beware of this case. Perhaps the solution is to just audit our usages and see where we've messed up. > 2- Implement the r-value ctors to allocate. This is likely going to require an additional member to capture the...

...cally 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...

Hi all- I am mostly doing work in Clang (and am new there), so I apologize if this isn't the proper place to mention this. I appreciate guidance in advance. I was looking into some of the unit tests, and noticed that the ArrayRefTest.InitializerList, and thus the InitializerList constructor of ArrayRef (under normal use-case) hit undefined behavior. The test does the following: