I don't think any of this should be terribly controversial. The "Long term" part of the proposals might be, but that's not what you're talking about here, right?
These changes will presumably require adjustments to the Xcode project. If you can do that yourself, then that's great. If you need one of us to fix the projects, putting them up for review before checking in will give one of us a chance to apply the patch and fix the projects and then we can gang the two submissions so we don't leave trunk broken. Other than that I'm fine with you just checking in the changes. Jim > On Jan 31, 2017, at 7:58 PM, Zachary Turner <ztur...@google.com> wrote: > > Are you interested in seeing the followup patches for review (moving classes > from Core -> Utility etc), or does it sound reasonable just based on my > description? > > On Tue, Jan 31, 2017 at 6:05 PM Jim Ingham <jing...@apple.com> wrote: > BTW, not to exclude the positive because it doesn't need discussing: all the > rest of the changes you were proposing seem appropriate and good to me. > Thanks for taking the trouble to clean this up. > > Jim > > > On Jan 31, 2017, at 5:45 PM, Zachary Turner <ztur...@google.com> wrote: > > > > Yea, there may be value in both. If i ever tried to do this I'd probably > > take the approach of converting all the obvious cases first that should > > enforce checking and then see what's left. Then we could use llvm:Error and > > lldb::Status, or something > > On Tue, Jan 31, 2017 at 5:39 PM Jim Ingham <jing...@apple.com> wrote: > > Yeah, I have no idea how you'd make sure that the SBError returned to > > Python in a Python SBValue was checked before it went out of scope, and I'm > > not sure it's our business to be enforcing that... So we're going to have > > to do something special for those errors. We also use the pattern where we > > return a count and an error, but ofttimes you don't care why you got > > nothing, so you just check the count. The error is informational. Making > > that obnoxious would also not be a plus. I actually think there's some > > value to having "programming errors that must be checked" and informational > > errors. Maybe we need both. > > > > Jim > > > > > On Jan 31, 2017, at 5:32 PM, Zachary Turner <ztur...@google.com> wrote: > > > > > > llvm::Error only enforces checking at the point that it goes out of > > > scope. So the example you mention should be supported, as long as you > > > propagate the value all the way up and don't destroy it. There's also > > > ways to explicitly ignore an Error (similar to casting to void to make > > > the compiler not warn about unused variables), so as a last resort we > > > could put code like that in the SB implementation if we had to > > > On Tue, Jan 31, 2017 at 5:23 PM Jim Ingham <jing...@apple.com> wrote: > > > I think we discussed this before, but we need an informational error > > > object. IIRC, the llvm::Error has to be checked. But for instance if > > > you ask a value object to evaluate itself, but you've moved to a section > > > of code where the variable has no location, then evaluating that value > > > will result in an error. But that isn't an error the value object code > > > needs to do anything about. And it might go all the way up through the > > > SB & Python API's before it's appropriate to check the error. > > > > > > IIRC, the llvm::Error is one of those "you have to check it or you get > > > smacked by the compiler" dealies. That's appropriate for some of our > > > uses of Error, but not all. > > > > > > Jim > > > > > > > > > > On Jan 31, 2017, at 4:01 PM, Zachary Turner via Phabricator via > > > > lldb-commits <lldb-commits@lists.llvm.org> wrote: > > > > > > > > zturner added a comment. > > > > > > > >> Move Error from Core -> Utility > > > > > > > > Also, I almost forgot. > > > > > > > > Long term: Delete and use `llvm::Error` > > > > > > > > > > > > https://reviews.llvm.org/D29359 > > > > > > > > > > > > > > > > _______________________________________________ > > > > lldb-commits mailing list > > > > lldb-commits@lists.llvm.org > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > > > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
