On Thu, Oct 4, 2012 at 4:03 PM, Villmow, Micah <[email protected]>wrote:
> ** ** > > ** ** > > *From:* Chandler Carruth [mailto:[email protected]] > *Sent:* Thursday, October 04, 2012 3:56 PM > *To:* Villmow, Micah > *Cc:* Kim Gräsman; Evan Cheng; [email protected] LLVM; Nadav > Rotem; [email protected] cfe > > *Subject:* Re: [cfe-commits] [llvm-commits] [Patch] Move TargetData from > Target to Support/VMCore**** > > ** ** > > On Thu, Oct 4, 2012 at 3:51 PM, Villmow, Micah <[email protected]> > wrote:**** > > I'm curious how this could work.**** > > **** > > I have two classes.**** > > TargetData and DataLayout.**** > > **** > > I want to point all uses of TargetData at DataLayout.**** > > **** > > typedef won't work not just because of forward declarations, but also > because of static functions.**** > > **** > > So, I could define DataLayout as a subclass of TargetData, but once I want > to move to DataLayout, how do I define TargetData in a way that won't > require changes to many many locations.**** > > ** ** > > I think you need to reverse the suggestion and instead use:**** > > ** ** > > class TargetData {**** > > // existing code**** > > };**** > > ** ** > > class DataLayout : public TargetData {**** > > // some forwarding boilerplate**** > > }**** > > ** ** > > Then you can change everyone to refer to DataLayout, and then lift the > implementation of TargetData up into DataLayout.**** > > ** ** > > You'll have to change folks to refer to DataLayout in o "top-down" way -- > producers first.**** > > *[Villmow, Micah] This is a good suggestion, but I was actually thinking > of doing it in the reverse. Turn TargetData into the forwarding > boilerplate, but I just wanted to make sure this was the intention instead > of moving forward and having to redo some work.* > > ** > The reason I suggest this direction is because it seems slightly easier to update the producers first, and the consumers second. But that's subjective. > * * > > *What subprojects do I need to modify?* > > *Clang/LLVM/compiler-RT I know* > > * * > > *Others would be LLDB, dragonegg, vmkit?* > > * * > > *What about libc++/polly/klee/safecode, etc...?* > LLDB, dragonegg, vmkit, klee, safecode, and polly seem the likel suspects. But some searching will help here. ;] > ** > > * **Basically what is the line that separates which projects need to be > updated by myself and what needs to be updated by their owners?* > The ones checked into llvm-projects SVN tree should be updated by you where possible. The ones with build bots as well definitely need to be updated. The only ones of your set without build bots are vmkit, klee, and safecode. For the ones with build bots, I think it's fine to essentially speculatively fix them. The bots will complain if something goes wrong. > * * > > *Thanks,* > > *Micah* > > ** ** > > ** ** > > **** > > Micah**** > > **** > > *From:* Kim Gräsman [mailto:[email protected]] > *Sent:* Thursday, October 04, 2012 1:33 PM > *To:* Villmow, Micah > *Cc:* Chris Lattner; Evan Cheng; [email protected] LLVM; > [email protected] cfe; Nadav Rotem**** > > > *Subject:* Re: [cfe-commits] [llvm-commits] [Patch] Move TargetData from > Target to Support/VMCore**** > > **** > > HI Micah,**** > > > > On Thursday, October 4, 2012, Villmow, Micah wrote:**** > > Chris, the problem with steps #2/#3 is that plenty of clients have forward > declarations of TargetData and the typedef won't work in this case, so I > need to update the clients anyways.**** > > **** > > One trick I've used as an alternative to typedefs is to just derive from > the old class, e.g.**** > > **** > > class NewName : public TargetData {};**** > > **** > > This is forward-declarable just as well as TargetData itself.**** > > **** > > FWIW,**** > > - Kim**** > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits**** > > ** ** >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
