clayborg added a comment. In D79811#2035078 <https://reviews.llvm.org/D79811#2035078>, @shafik wrote:
> In D79811#2034842 <https://reviews.llvm.org/D79811#2034842>, @clayborg wrote: > > > The error where two of the same classes conflicted usually only happened > > in complex cases that were hard to reduce down. > > > > If I understand this correctly, the compiler should be able to auto > > synthesize these functions at will since the original class definition > > should have all of the information it needs to create them. So why do we > > need these to be added? Seems like the wrong approach IMHO. I would like > > the hear the justification for needing to add artificial functions to a > > class definition before we entertain this more. Can you elaborate on why > > you think these are needed? > > > Yes, the test case below shows that if we don't add the method then during > expression evaluation of let's say: > > A{} > > > The `default member initializer` won't be done. So `x` won't be initialized > to `10` and the default constructor for `cse` will be called instead of > `ClassForSideEffect(int)`. So that sounds like a compiler bug or something that we are not setting up right in the class type when we convert it from DWARF. Can you compile a quick example and dump the AST somehow and then compare it to the class we generate from debug info and see how they differ? 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
