[ASTImporter][AST] Fix structural equivalency crash on dependent FieldDecl

[martong]

The added test causes the below assertion in the baseline (w/o the fix):

ASTTests: ../../git/llvm-project/clang/lib/AST/ExprConstant.cpp:14543: llvm::APSInt clang::Expr::EvaluateKnownConstInt(const clang::ASTContext&, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >*) const: Assertion `!isValueDependent() && "Expression evaluator can't be called on a dependent expression."' failed.

[shafik]

So was the bug we were saying there were falsely equivalent or falsely not equivalent?

[teemperor]

Shouldn't this compare the actual width expressions? In other words, this patch wouldn't pass the test below:

TEST_F(StructuralEquivalenceTemplateTest, DependentFieldDeclDifferentVal) {
  const char *Code1 = "template <class A, class B> class foo { int a : sizeof(A); };";
  const char *Code2 = "template <class A, class B> class foo { int a : sizeof(B); };";
  auto t = makeNamedDecls(Code1, Code2, Lang_CXX03);
  EXPECT_FALSE(testStructuralMatch(t));
}

I don't want to derail the simple crash fix here, but I'm tempted to say that we might as well just simplify all this to return IsStructurallyEquivalent(Context, Field1->getBitWidth(), Field2->getBitWidth());. The nice diagnostic could live behind behind a check that ensures that both widths are not value-dependent.

If you want to keep this simple because you want to backport it I would also be fine with the current patch (not crashing is clearly an improvement)

In D88665#2307562, @shafik wrote:

So was the bug we were saying there were falsely equivalent or falsely not equivalent?

I think the bug is the crash :)

[martong]

In D88665#2307562, @shafik wrote:

So was the bug we were saying there were falsely equivalent or falsely not equivalent?

I think the bug is the crash :)

Yes. More specifically, the call of getBitWidthValue() caused a segfault with release builds and with assertions enabled it caused the mentioned assert on the given test code.

In D88665#2307945, @teemperor wrote:

Shouldn't this compare the actual width expressions? In other words, this patch wouldn't pass the test below:

TEST_F(StructuralEquivalenceTemplateTest, DependentFieldDeclDifferentVal) {
  const char *Code1 = "template <class A, class B> class foo { int a : sizeof(A); };";
  const char *Code2 = "template <class A, class B> class foo { int a : sizeof(B); };";
  auto t = makeNamedDecls(Code1, Code2, Lang_CXX03);
  EXPECT_FALSE(testStructuralMatch(t));
}

Yes, absolutely, it should. I have updated the patch this way, thanks! However, I was struggling to pass the existing lit test (ASTMerge/struct/test.c). Finally, I decided to remove all the BitField diagnostic code because it was already flawed - we called getBitWidthValue unchecked.

Currently, we are totally inconsistent about the diagnostics. Either we should emit a diagnostic before all return false or we should not ever emit any diags. The diagnostics in their current form are misleading, because there could be many notes missing. I am not sure how much do you guys value these diags in LLDB, but in CTU we simply don't care about them. I'd rather remove these diags from the equivalency check code, because they are causing only confusion. (Or we should properly implement and test all aspects of the diags.)

[martong]

• Delegate to BitWidth Expr matching in case of BitFields

[shafik]

In D88665#2308366, @martong wrote:

In D88665#2307562, @shafik wrote:

So was the bug we were saying there were falsely equivalent or falsely not equivalent?

I think the bug is the crash :)

Yes. More specifically, the call of getBitWidthValue() caused a segfault with release builds and with assertions enabled it caused the mentioned assert on the given test code.

Thank you! From the test it was not obvious what was the actual cause of the crash so evaluating the correctness was difficult.

[teemperor]

LGTM, thanks!

[teemperor]

I am not sure how much do you guys value these diags in LLDB

I think we don't even display them most of the time (IIUC they go to the diagnostic engine which is not always hooked up for the ASTs in LLDB as only a few actually come from Clang).

[martong]

Currently, we are totally inconsistent about the diagnostics. Either we should emit a diagnostic before all return false or we should not ever emit any diags. The diagnostics in their current form are misleading, because there could be many notes missing. I am not sure how much do you guys value these diags in LLDB, but in CTU we simply don't care about them. I'd rather remove these diags from the equivalency check code, because they are causing only confusion. (Or we should properly implement and test all aspects of the diags.)

In D88665#2311344, @teemperor wrote:

LGTM, thanks!

Thanks for the review!

clang/lib/AST/ASTStructuralEquivalence.cpp

if (Context.Complain) {
         Context.Diag1(Field1->getLocation(), diag::note_odr_not_bit_field)
             << Field1->getDeclName();
       }
     }
     return false;
   }
 
   if (Field1->isBitField()) {
+    bool isVD1 = Field1->getBitWidth()->isValueDependent();
+    bool isVD2 = Field2->getBitWidth()->isValueDependent();
+    if (isVD1 || isVD2)
+      return isVD1 && isVD2;
     // Make sure that the bit-fields are the same length.
     unsigned Bits1 = Field1->getBitWidthValue(Context.FromCtx);
     unsigned Bits2 = Field2->getBitWidthValue(Context.ToCtx);
 
     if (Bits1 != Bits2) {
       if (Context.Complain) {
         Context.Diag2(Owner2->getLocation(),
                       Context.getApplicableDiagnostic(

clang/unittests/AST/StructuralEquivalenceTest.cpp

 }
 
 TEST_F(StructuralEquivalenceTemplateTest, DifferentTemplateArgKind) {
   auto t = makeNamedDecls("template <class T> struct foo;",
                           "template <int T> struct foo;", Lang_CXX03);
   EXPECT_FALSE(testStructuralMatch(t));
 }
 
+TEST_F(StructuralEquivalenceTemplateTest, DependentFieldDecl) {
+  const char *Code = "template <class T> class foo { int a : sizeof(T); };";
+  auto t = makeNamedDecls(Code, Code, Lang_CXX03);
+  EXPECT_TRUE(testStructuralMatch(t));
+}
+
 TEST_F(StructuralEquivalenceTemplateTest, ExplicitBoolSame) {
   auto Decls = makeNamedDecls(
       "template <bool b> struct foo {explicit(b) foo(int);};",
       "template <bool b> struct foo {explicit(b) foo(int);};", Lang_CXX20);
   CXXConstructorDecl *First = FirstDeclMatcher<CXXConstructorDecl>().match(
       get<0>(Decls), cxxConstructorDecl(hasName("foo<b>")));
   CXXConstructorDecl *Second = FirstDeclMatcher<CXXConstructorDecl>().match(
       get<1>(Decls), cxxConstructorDecl(hasName("foo<b>")));