[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