Chris Lattner wrote:> The two patches I didn't apply are the one that affects the interpreter > (I'll let Brian tackle it as he's the interpreter guy), and this one: > > ==================================================================> RCS file: /var/cvs/llvm/llvm/include/llvm/CodeGen/MachineBasicBlock.h,v > retrieving revision 1.39 > diff -u -r1.39 MachineBasicBlock.h > --- include/llvm/CodeGen/MachineBasicBlock.h 1 Sep 2004 22:55:34 -0000 1.39 > +++ include/llvm/CodeGen/MachineBasicBlock.h 25 Oct 2004 08:29:24 -0000 > @@ -18,6 +18,8 @@ > #include "llvm/ADT/GraphTraits.h" > #include "llvm/ADT/ilist" > #include <iosfwd> > +#include <algorithm> > +#include <functional> > > namespace llvm { > class MachineFunction; > > For this change, I'd rather not put those extra #includes into a main > header like that. Could you please move the inline methods that need the > #includes out-of-line into MachineBasicBlock.cpp, then add the #include's > there?the <functional> is needed because of this declaration: struct MachineBasicBlock2IndexFunctor : std::unary_function<const MachineBasicBlock*, unsigned> { How can it be moved?? removing the <algorithm> caused a few more files to require including this header, I'm attaching a patch to this message. By the way, I'm getting 2356 warnings when I build the project - most of them are either "type name first seen using 'struct' now seen using 'class'" or "type name first seen using 'class' now seen using 'struct'" -- are there any plans to clean this up? I saw the coding guidelines for LLVM says something about the use of struct vs. class, but it doesn't seem like this is well enforced across the project. My personal opinion is that 'struct' should only be used for something which a plain C compiler would recognize...> If I missed any of the patches or messed them up, please let me know. :) > Thanks for the great patches!Thanks for the support! My diff is almost empty now, so I will start working on integrating LLVM with our project ... m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041026/0ff92451/attachment.txt>
Morten Ofstad wrote:> the <functional> is needed because of this declaration: > > struct MachineBasicBlock2IndexFunctor > : std::unary_function<const MachineBasicBlock*, unsigned> {Which appears not to be used anywhere... Maybe you can just delete it (and the #include <algorithm> with it)? m.
On Oct 26, 2004, at 11:06 AM, Morten Ofstad wrote:> I saw the coding guidelines for LLVM says something about the use of > struct vs. class, but it doesn't seem like this is well enforced > across the project.It's a recent addition to the guidelines, and it was added precisely for the class vs struct ABI problem with VC... --- Paolo Invernizzi
On Tue, 26 Oct 2004, Morten Ofstad wrote:> the <functional> is needed because of this declaration: > > struct MachineBasicBlock2IndexFunctor > : std::unary_function<const MachineBasicBlock*, unsigned> { > > How can it be moved??You're right, it can't, except that MachineBasicBlock2IndexFunctor is dead, so I nuked it.> removing the <algorithm> caused a few more files to require including > this header, I'm attaching a patch to this message.Sounds good, patches applied: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041025/019854.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041025/019855.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041025/019856.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041025/019857.html Thanks!> By the way, I'm getting 2356 warnings when I build the project - most of > them are either "type name first seen using 'struct' now seen using > 'class'" or "type name first seen using 'class' now seen using 'struct'" > -- are there any plans to clean this up? I saw the coding guidelines for > LLVM says something about the use of struct vs. class, but it doesn't > seem like this is well enforced across the project. My personal opinion > is that 'struct' should only be used for something which a plain C > compiler would recognize...As Paolo pointed out, this is a recent addition to the coding standards, in response to VC's (buggy) requirement that class & struct match up. We would be happy to accept patches that convert struct -> class in the appropriate places, and I agree with your intuition of what should be a class vs a struct.> > If I missed any of the patches or messed them up, please let me know. :) > > Thanks for the great patches! > > Thanks for the support! My diff is almost empty now, so I will start > working on integrating LLVM with our project ...Great! Let us know how it goes and if you run into any other problems! -Chris -- http://llvm.org/ http://nondot.org/sabre/
Chris Lattner wrote:> We would be happy to accept patches that convert struct -> class in the > appropriate places, and I agree with your intuition of what should be a > class vs a struct.Here is a (big) patch which makes the struct/class usage consistent - I think probably some structs should be classes, but most of the time I made the choice that required changes in as few places as possible... m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041027/050adbc3/attachment.txt>