malcolm.parsons added inline comments.
================ Comment at: clang-tidy/readability/RedundantMemberInitCheck.cpp:57 "initializer for base class %0 is redundant") - << Init->getTypeSourceInfo()->getType() + << Construct->getType() << FixItHint::CreateRemoval(Init->getSourceRange()); ---------------- malcolm.parsons wrote: > aaron.ballman wrote: > > malcolm.parsons wrote: > > > aaron.ballman wrote: > > > > Why is it more correct to use the CXXConstructExpr type information > > > > rather than the CXXCtorInitializer? > > > Something to do with templates and namespaces. > > > > > > In the bug report, `CXXCtorInitializer` had type `std::__1::bitset<128>` > > > and `CXXConstructExpr` had type `std::bitset<MAX_SUBTARGET_FEATURES>`. > > > > > > I don't know why. > > I believe it's because `__1` is an inline namespace, and the printing > > policy matters. IIRC, there's the `SuppressUnwrittenScope` policy data > > member, that if you set it to true, it won't print the inline or anonymous > > namespace when printing types. > > > > We should understand why there's a difference before applying this change. > > I think using the CXXCtorInitializer's type is more correct than using the > > CXXConstructExpr's type (due to implicit type conversions). Given that the > > printing policy controls whether inline namespaces are printed, I would > > have expected these both to print without the inline namespace (the type > > changed, but not the printing policy) -- the fact that the behavior differs > > makes me worried there's a bug somewhere else and this fix is masking it. > The difference isn't just the scope; `MAX_SUBTARGET_FEATURES` became `128` > too. > > Looking at `Sema::BuildMemInitializer()` didn't help me. The lookup of the base type has a Path with sugared type, but the Decl found has a canonical type. https://reviews.llvm.org/D26118 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits