<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 7, 2009, at 1:29 PM, Misha Brukman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">2009/1/3 Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div><div><div>On Jan 2, 2009, at 1:48 PM, Misha Brukman wrote:</div><blockquote type="cite">2009/1/2 Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span><br> <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div><div><div><div>On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:</div> </div></div></div><div>Do you have a specific example of a unit test that would need these? I really think these should stay private.</div> </div></blockquote><div><br>Let's take lib/Transforms/Utils/CodeExtractor.cpp . The public interface for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the high-level API.<br> <br>If I want to test some corner-case (consider the number of code paths in that code), I have to strain to come up with some combination of a Function and input BasicBlocks that will fit all the conditions from the outset. Or, I can just feed each individual method in the class exactly the corner cases I will want it to handle, and verify its output (or side effects) exactly, to make sure I pin-pointed the issue.</div> </div></blockquote></div>Sure, ok. But that is a public API, I'm specifically interested in cases you need private API.</div></div></blockquote><div><br>I'm not sure I understand what you mean. What I am saying is that I want to expose the innards of CodeExtractor.cpp in a header file, #include that in the unittest, and move the implementation out of an anonymous namespace into llvm::transforms::utils, or llvm::internal::transforms::utils, or similar, so it can be unit-tested. This is not about exposing the private API to end-users of LLVM or even other LLVM libraries, just unittests.<br> <br>The public API, while useful to the end-user, is limiting when it comes to unit-testing. "Unit" in this case is a single method of the actual implementation (i.e., a method of the CodeExtractor class), not a single function call of the high-level exported public API, which will exercise the entire class and its many methods.<br> </div> </div></blockquote></div><br><div>I am pretty strongly against that. Specifically for CodeExtractor, what benefit do you gain by doing this?</div><div><br></div><div>-Chris</div></body></html>