search for: iterator_range

Hello, Our llvm::iterator_range is quite minimalist in design, it does not even have an "empty" method. Is that because we want it to work on all iterators (including those dirty OutputIterator)? Maybe we can add a little bit to it? I recently needed: - bool empty() - value_type& font() - value_type& back() -...

Hi all, As RFCs go this is short and sweet - I think it would be nice to add an empty method to iterator_range. Something like: bool empty() const { return begin() != end(); } My motivation is to make the 'if' test at the start of this common pattern tidier: if (!collection.empty()) // initialization... for (auto& c : collection) // do something for each c. which I think that is preferab...

...Mar 19, 2014, at 11:32 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Wed, Mar 19, 2014 at 2:13 PM, Lang Hames <lhames at gmail.com> wrote: >> Hi all, >> >> As RFCs go this is short and sweet - I think it would be nice to add an >> empty method to iterator_range. Something like: >> >> bool empty() const { return begin() != end(); } >> >> My motivation is to make the 'if' test at the start of this common pattern >> tidier: >> >> if (!collection.empty()) >> // initialization... >> for (auto&am...

...ve? Is there any reason not to follow that approach? Cheers, Lang. On Thu, Mar 20, 2014 at 2:31 PM, Chandler Carruth <chandlerc at google.com>wrote: > Since Richard first poked me about this, I'm still debating this. > > I'm torn in a bunch of different ways: > > 1) iterator_range is *not* a container. It shouldn't and can't be used > like one. > 2) members are really hard to extend. they make templates harder not > easier because the widen the set of interfaces which *must* be on a given > container > 3) the concept of testing for emptiness is actuall...

Trying to build LLVM 3.8 (or trunk) with the 2016 Intel C++ compiler. It fails on the std::declval feature: llvm-3.8/include/llvm/ADT/iterator_range.h(63): error: namespace "std" has no member "declval" iterator_range<decltype(begin(std::declval<T>()))> drop_begin(T &&t, int n) { An isolated std::declval example shows that this compiler doesn't support it. I can't really roll back to an ear...

...he other secondary ranges hanging off IR and other things). IMO, "for (auto &arg : F.getArguments())" makes the most sense. > > I was actually going to check in this, but I can post it for review if folks are worried. > > My plan was to provide an implementation of std::iterator_range<T> and then provide 'F.arguments()' which returns it. Nice. What's the logic behind .arguments() vs .getArguments()? I don't have a strong opinion either way, but there should be rationale. -Chris -------------- next part -------------- An HTML attachment was scrubbed......

...ption. opt: /home/jayfoad2/git/llvm-project/llvm/lib/Analysis/SyncDependenceAnalysis.cpp:312: std::unique_ptr<ConstBlockSet> llvm::DivergencePropagator::computeJoinPoints(const llvm::BasicBlock &, SuccessorIterable, const llvm::Loop *, const llvm::BasicBlock *) [SuccessorIterable = llvm::iterator_range<llvm::SuccIterator<const llvm::Instruction, const llvm::BasicBlock> >]: Assertion `HeaderDefBlock && "no definition in header of carrying loop"' failed. Stack dump: 0. Program arguments: /home/jayfoad2/llvm-debug/bin/opt -use-gpu-divergence-analysis -divergence str...

...umpOptions) /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFCompileUnit.cpp:31:0 #22 0x00000000004482ad llvm::DWARFContext::dump(llvm::raw_ostream&, llvm::DIDumpOptions, std::array<llvm::Optional<unsigned long>, 27ul>)::'lambda0'(bool, char const*, llvm::DWARFSection, llvm::iterator_range<std::unique_ptr<llvm::DWARFCompileUnit, std::default_delete<llvm::DWARFCompileUnit> >*>)::operator()(bool, char const*, llvm::DWARFSection, llvm::iterator_range<std::unique_ptr<llvm::DWARFCompileUnit, std::default_delete<llvm::DWARFCompileUnit> >*>) const /home/l...

...it possible to change the source of MemorySSA.cpp to hide the problem and buy some time for now? Now we use an empty generic_def_path_iterator with Optional<ListIndex> N being initialized by None as the end of range. Can we initialize the Optional var with a special value instead of None? iterator_range<def_path_iterator> def_path(ListIndex From) { return make_range(def_path_iterator(this, From), def_path_iterator()); } On Mon, Jul 17, 2017 at 1:37 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > I think everyone agrees pretty much everything short of "Fix undef&quot...

...lib/DebugInfo/DWARF/DWARFCompileUnit.cpp:31:0 >> #22 0x00000000004482ad llvm::DWARFContext::dump(llvm::raw_ostream&, >> llvm::DIDumpOptions, std::array<llvm::Optional<unsigned long>, >> 27ul>)::'lambda0'(bool, char const*, llvm::DWARFSection, >> llvm::iterator_range<std::unique_ptr<llvm::DWARFCompileUnit, >> std::default_delete<llvm::DWARFCompileUnit> >*>)::operator()(bool, char >> const*, llvm::DWARFSection, >> llvm::iterator_range<std::unique_ptr<llvm::DWARFCompileUnit, >> std::default_delete<llvm::DWARFComp...

On Mar 2, 2014, at 10:27 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Sun, Mar 2, 2014 at 10:13 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Sun, Mar 2, 2014 at 9:26 PM, Chris Lattner <sabre at nondot.org> wrote: > > On Mar 2, 2014, at 8:53 PM, Renato Golin <renato.golin at linaro.org> wrote: > > > On 3 March 2014

...Unit.cpp:31:0 >>>> #22 0x00000000004482ad llvm::DWARFContext::dump(llvm::raw_ostream&, >>>> llvm::DIDumpOptions, std::array<llvm::Optional<unsigned long>, >>>> 27ul>)::'lambda0'(bool, char const*, llvm::DWARFSection, >>>> llvm::iterator_range<std::unique_ptr<llvm::DWARFCompileUnit, >>>> std::default_delete<llvm::DWARFCompileUnit> >*>)::operator()(bool, char >>>> const*, llvm::DWARFSection, >>>> llvm::iterator_range<std::unique_ptr<llvm::DWARFCompileUnit, >>>> std::d...

> On Feb 2, 2019, at 8:18 PM, Chris Lattner <clattner at nondot.org> wrote: > > > >> On Feb 1, 2019, at 6:20 AM, Michael Platings via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi all, >> >> As application of the naming rules are currently under discussion [1] this seems like a good time

...SA.cpp to hide the problem and buy some time for now? Now we >> use an empty generic_def_path_iterator with Optional<ListIndex> N >> being initialized by None as the end of range. Can we initialize the >> Optional var with a special value instead of None? >> >> iterator_range<def_path_iterator> def_path(ListIndex From) { >> return make_range(def_path_iterator(this, From), def_path_iterator()); >> } >> > > Why does this work? Fwiw, I don't think this is a good idea. If it can happen in MemorySSA it can happen in other organic C++...

On 2014 Mar 2, at 22:27, Chandler Carruth <chandlerc at google.com> wrote: > > On Sun, Mar 2, 2014 at 10:13 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Sun, Mar 2, 2014 at 9:26 PM, Chris Lattner <sabre at nondot.org> wrote: > > On Mar 2, 2014, at 8:53 PM, Renato Golin <renato.golin at linaro.org> wrote: > > > On 3 March 2014

Dear testers, 5.0.0-rc3 was just tagged. This is a release candidate in the real sense: if nothing bad comes up in testing, this is what the release is going to look like. Please build, test and upload binaries to the sftp (use the /data/testers-uploads/ directory) and let me know what issues remain. I know we're a little bit behind schedule, but hopefully we can get to 'final'

On Mar 3, 2014, at 12:04 AM, Chandler Carruth <chandlerc at google.com> wrote: >> I was actually going to check in this, but I can post it for review if folks are worried. >> >> My plan was to provide an implementation of std::iterator_range<T> and then provide 'F.arguments()' which returns it. > > Nice. What's the logic behind .arguments() vs .getArguments()? I don't have a strong opinion either way, but there should be rationale. > > In the best case 'get' doesn't really add any meani...

...empty generic_def_path_iterator with Optional<ListIndex> N > >>>> being initialized by None as the end of range. Can we > initialize the > >>>> Optional var with a special value instead of None? > >>>> > >>>> iterator_range<def_path_iterator> def_path(ListIndex From) { > >>>> return make_range(def_path_iterator(this, From), > def_path_iterator()); > >>>> } > >>>> > >>> > >>> Why does this work? > >>...

...ntions would cause some churn and confusion, but we *already* have that, as the current nominal conventions aren't in place in the entire codebase. Regarding snake_case, LLVM has very limited use of that, and only for things that are (a) substitutes or (b) extensions of STL features. "iterator_range" for example. camelCase predominates. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris Lattner via llvm-dev Sent: Saturday, February 02, 2019 11:19 PM To: Michael Platings Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> ; n...

...time for now? Now we >>>> use an empty generic_def_path_iterator with Optional<ListIndex> N >>>> being initialized by None as the end of range. Can we initialize the >>>> Optional var with a special value instead of None? >>>> >>>> iterator_range<def_path_iterator> def_path(ListIndex From) { >>>> return make_range(def_path_iterator(this, From), def_path_iterator()); >>>> } >>>> >>> >>> Why does this work? >> >> Fwiw, I don't think this is a good idea. If it c...