[LLVMbugs] [Bug 23552] New: parsing regression

[bugzilla-daemon at llvm.org]

https://llvm.org/bugs/show_bug.cgi?id=23552

            Bug ID: 23552
           Summary: parsing regression
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: legalize at xmission.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 14334
  --> https://llvm.org/bugs/attachment.cgi?id=14334&action=edit
clang-query session

See the attached clang-query session.  The installed version is 3.5.0 and the
version run from my build tree is trunk.

In 3.5.0 clang-query correctly reports two if statements for this code from
clang/lib/AST/ExprConstant.cpp:

    bool isOnePastTheEnd() const {
      assert(!Invalid);
      if (IsOnePastTheEnd)
        return true;
      if (MostDerivedArraySize &&
          Entries[MostDerivedPathLength - 1].ArrayIndex ==
MostDerivedArraySize)
        return true;
      return false;
    }

In trunk, the 2nd if statement is missing from the parse tree.  I noticed this
while working on an enhancement for clang-tidy's
readability-simplify-boolean-expr check.  I was adding a simplification of:

    if (expr)
      return true;
    return false;

into

    return expr;

When I tried it out on llvm/clang trunk, I got all kinds of erroneous changes. 
I didn't find anything in the debugger so I went to clang-query to dump out the
AST and the 2nd if statement in the above method is completely missing from the
AST.  This causes the matcher to fire on the first if statement and the last
return statement, changing the meaning of the code.

My simplifier was doing this pretty consistently throughout the code matching
stuff of the form:

    if (expr)
      return true;
    arbitrary_stmt;
    return false;

and stuff of the form:

    if (expr) {
      arbitrary_stmt;
      return true;
    }
    return false;

My matcher was using an expression like this:

      compoundStmt(
          allOf(hasAnySubstatement(
                    ifStmt(
                        hasThen(returnsBool(Value, CompoundId)),
                       
unless(hasElse(stmt()))).bind(CompoundIfReturnsBoolId)),
                hasAnySubstatement(returnStmt(has(boolLiteral(equals(!Value))))
                                       .bind(CompoundReturnId)))).bind(Id)

where returnsBool is my own helper that does:

    internal::Matcher<Stmt> returnsBool(bool Value, StringRef Id = "") {
      auto SimpleReturnsBool =
          returnStmt(
              has(boolLiteral(equals(Value)).bind(Id.empty() ? "ignored" :
Id)))
              .bind("returns-bool");
      return anyOf(SimpleReturnsBool,
                   compoundStmt(statementCountIs(1), has(SimpleReturnsBool)));
    }

...which means that there's something even more wrong afoot because if
statements with a then clause containing a compound statement of more than one
statement shouldn't even trigger a match, but they are.

I don't think anything I've done caused this problem, since I am only making
changes on clang-tidy.  The full changeset is available for review at
http://reviews.llvm.org/D9810.  I am on master branch of llvm and clang using
the github mirror.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150517/75891b01/attachment.html>