[LLVMbugs] [Bug 12715] New: Unnecessary "typename" qualification can still cause errors with MicrosoftExt in some cases.

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue May 1 08:05:27 PDT 2012


http://llvm.org/bugs/show_bug.cgi?id=12715

             Bug #: 12715
           Summary: Unnecessary "typename" qualification can still cause
                    errors with MicrosoftExt in some cases.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: lantictac at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I've run into a issue parsing headers where the following constructs are
(frequently) used and successfully compiled by the MSVC compilers:

template <typename T>
class Foo
{
  typedef typename T* pT;
};

The additional typename qualification is unnecessary and causes the following
warning to be emitted from Parser::TryAnnotateTypeOrScopeToken():

warning: expected a qualified name after 'typename'
        typedef typename T* pT;

Which is fine and expected, however the parsing quickly fails with:

error: expected ';' at end of declaration list
        typedef typename T* pT;

This appears to be due the return true (error occurred) from
TryAnnotateTypeOrScopeToken() even though the occurrence is treated as a
warning.

Interestingly the original commit that introduced the warning (r130088 by
fpichet) states the following:

"Must "return true;" even if it is a warning because the rest of the code path
assumes that SS is set to something. The parser will get back on its feet and
continue parsing the rest of the declaration correctly so it is not a problem."

It's true that the rest of the code expects SS to be valid, but unfortunately
the assumption that the "parser will get back on its feet" is not true with the
current implementation.

I tried a naive return false (no error) in the event of the
diag::warn_expected_qualified_after_typename instance and the parser appeared
to recover successfully, but being unfamiliar with the logic in question I
wonder if that is the correct approach for recovery in this case?

-- 
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