[LLVMbugs] [Bug 11150] New: Pure virtual specifiers broken when Microsoft extensions are turned on
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Mon Oct 17 00:34:38 PDT 2011
http://llvm.org/bugs/show_bug.cgi?id=11150
Summary: Pure virtual specifiers broken when Microsoft
extensions are turned on
Product: clang
Version: trunk
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: Frontend
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: johnw at boostpro.com
CC: llvmbugs at cs.uiuc.edu
Doug Gregor's change r141539, which removes the Init argument from
Sema::ActOnCXXMemberDeclarator, causes a problem with Microsoft extensions and
pure virtual specifiers.
There is this code in ParseDeclCXX.cpp
(Parser::ParseCXXClassMemberDeclaration):
if (getLang().MicrosoftExt && Tok.is(tok::equal) &&
DeclaratorInfo.isFunctionDeclarator() &&
NextToken().is(tok::numeric_constant)) {
ConsumeToken();
Init = ParseInitializer();
if (Init.isInvalid())
SkipUntil(tok::comma, true, true);
}
This code gets executed for every kind of pure virtual function, causing Init
to be set. Before r141539, Sema::ActOnCXXMemberDeclarator would see that Init
was set and call AddInitializerToDecl. This code path is ultimately
responsible for setting Abstract on the class.
With the change, that code moved to Parser::ParseCXXClassMemberDeclaration --
but only if HasInitializer is true, which it never is if the above Microsoft
extension code has consumed the tok::equal that would normally trigger
HasInitializer getting set in Parser::ParseCXXClassMemberDeclaration:
bool HasInitializer = false;
bool HasDeferredInitializer = false;
if (Tok.is(tok::equal) || Tok.is(tok::l_brace)) {
if (BitfieldSize.get()) {
Diag(Tok, diag::err_bitfield_member_init);
SkipUntil(tok::comma, true, true);
} else {
HasInitializer = true; // <---------
HasDeferredInitializer = !DeclaratorInfo.isDeclarationOfFunction() &&
DeclaratorInfo.getDeclSpec().getStorageClassSpec()
!= DeclSpec::SCS_static &&
DeclaratorInfo.getDeclSpec().getStorageClassSpec()
!= DeclSpec::SCS_typedef;
}
}
I'm not sure what the best way to fix this is. I have a feeling the Microsoft
extension code that's doing the eager parsing needs to be rewritten for the new
logic.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list