[llvm-bugs] [Bug 43080] New: Assertion `E->isNonOdrUse() != NOUR_Unevaluated && "should not emit an unevaluated operand"' with sizeof

[via llvm-bugs]

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

            Bug ID: 43080
           Summary: Assertion `E->isNonOdrUse() != NOUR_Unevaluated &&
                    "should not emit an unevaluated operand"' with sizeof
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: efriedma at quicinc.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Testcase (C++):

int f(int i) { return sizeof i<i; }

clang-10: [...]/llvm/tools/clang/lib/CodeGen/CGExpr.cpp:2518:
clang::CodeGen::LValue clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(const
clang::DeclRefExpr *): Assertion `E->isNonOdrUse() != NOUR_Unevaluated &&
"should not emit an unevaluated operand"' failed.


What I think is happening is that the parser sees "i<", so ParseCastExpression
calls checkPotentialAngleBracket.  That tries to speculatively parse the second
"i", to try to disambiguate a template-id.  It then backs out, but at that
point we've already annotated the token with a DeclRefExpr.  That DeclRefExpr
is incorrectly marked unevaluated because "isUnevaluatedContext()" is true when
the expression is created.

We could probably teach mightBeIntendedToBeTemplateName so it knows that a
local variable is never a template name... that avoids the problem here.  And I
think we can always determine whether a expression is "considered to refer to a
template" per [temp.names]?  But that makes diagnostics worse on some
testcases. And I'm not sure checkPotentialAngleBracket is the only way to
trigger this sort of issue.

Alternatively, we could try to solve the issue at the point we parse the
annotated token.  Maybe we could throw away the expression?  Rewrite the
expression it like we do typeid() expressions?  Something else?

The assertion is new in r363295, but the issue isn't, I think.  This particular
formulation triggers a different assertion on older versions of clang.

-- 
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/20190821/311494c5/attachment-0001.html>