labath added a comment. In general, I think this is a good direction to go in. We can run into the same kinds of problems even with non-artificial functions -- either the application can have real ODR violations, or we can introduce ODR violations during expression eval by playing fast-and-loose with anonymous namespaces.
For all of those cases we need a more general approach to handling the "I have two versions of a class, and they don't really match" problem. As for a test case where this would fail, I haven't had first hand experience with this, but I would guess it involves two shared libraries, one which contains the definition of this artificial constructor, and one which doesn't. And then pulling both of these class definitions into the same expression... ================ Comment at: lldb/test/API/lang/cpp/constructors/main.cpp:11 + int x=10; + ClassForSideEffect cse = ClassForSideEffect(100); }; ---------------- Just for my own education, how would this fail without the patch? During expression evaluation, we would synthesize a call to the default constructor of `ClassForSideEffect`, instead of the one taking int=100? Or is it something else? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79811/new/ https://reviews.llvm.org/D79811 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
