[cfe-commits] [PATCH] Allow typedef with unnecessary "typename" when ms-extensions are enabled.

[William Wilson]

Hi All,

This patch follows on from http://llvm.org/bugs/show_bug.cgi?id=12715
and includes a test case for validation. Local testing shows no
regression.

Original outline of issue from bug report:

----

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?

----

Other concerns:

Do I need to annotate the typename token before the return false?

Additionally, this recovery state seems more applicable to
ms-compatibility rather than ms-extensions, but as r130088 uses
MicrosoftExt I chose to leave it as is. Any thoughts?

All the best,
Will.

PS. Many thanks for all the excellent work. It's probably the finest
large-scale code base I've had the pleasure to work with.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unecessary_typename_msext.diff
Type: application/octet-stream
Size: 1531 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120502/65f50db4/attachment.obj>