rnk added a comment.
In http://reviews.llvm.org/D19479#435620, @rnk wrote:
> To deal with the specific case in ATL, we can use the 'new' expression as a
> hint that the unknown identifier is actually a dependent type. There should
> be some bit of context we can look at in DiagnoseUnknownTypeNa
rnk added a comment.
You've described the core issue with parsing C++ templates prior to
instantiation, you have to know what identifiers are types, and that's why we
need typename. :) MSVC only parses templates after instantiation, so it doesn't
need typename.
To deal with the specific case i
avt77 added a comment.
It seems I gave up with this issue :-( We have 2 possible situations here:
1. A type from instantiated type used inside the template (like in the test I'm
working on)
2. A feature from instantiated type used inside the template (like below)
struct A {
int bar ();
}
te
avt77 added a comment.
OK, I'll try to implement something like a DependentScopeDeclRefExpr but
because of the latest changes in Intel I'm afraid it will take some more time
from me.
http://reviews.llvm.org/D19479
___
cfe-commits mailing list
cfe-
rnk requested changes to this revision.
rnk added a comment.
This revision now requires changes to proceed.
We definitely should not rely on typo correction or other error recovery
mechanisms to do this for us. Otherwise we can end up accepting ill-formed
programs like this one:
struct MyStru
avt77 created this revision.
avt77 added a reviewer: rnk.
avt77 added a subscriber: cfe-commits.
This is the first patch to fix clang-cl incompatibility prohibited to compile
the header file. The patch covers the following case:
class CCommandBarCtrlBase {
public:
typedef int CMsgHookMap;
};
