I tried to replicate the way the existing ‘missing typename’ diagnostic behaved
for MSVC compatibility. Is there something more that needs to be done here?
I’m not sure how I can verify that the resulting IR is correct on Windows,
though...
> +void Sema::diagnoseMissingTypename(IdentifierInfo *II, SourceLocation IILoc,
> + Scope *S, CXXScopeSpec *SS) {
> + unsigned DiagID = diag::err_typename_missing;
> + if (getLangOpts().MSVCCompat && isMicrosoftMissingTypename(SS, S))
> + DiagID = diag::ext_typename_missing;
Ben
> On Feb 11, 2015, at 7:34 PM, Bataev, Alexey <[email protected]> wrote:
>
> Hi Ben,
> I don't think your patch is compatible with MSVC. MSVC accepts this code and
> clang should accept it and generate proper LLVM IR. Actually, you can run
> into similar code in MSVC system headers. That's the main problem
> Best regards,
> Alexey Bataev
> =============
> Software Engineer
> Intel Compiler Team
> Intel Corp.
> 11.02.2015 20:37, Ben Langmuir пишет:
>> Ping
>>
>>> On Jan 26, 2015, at 9:08 AM, Ben Langmuir <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> This patch diagnoses a missing ‘typename’ keyword on nested template types
>>> like A<T>::B<U>, to fix llvm.org/pr16909 <http://llvm.org/pr16909>. In
>>> addition to fixing an accepts-invalid, in C++11 such types would cause
>>> assertion failures and/or invalid LLVM IR when used with ‘auto’.
>>>
>>> I’m not 100% sure if the changes to
>>> test/CXX/basic/basic.lookup/basic.lookup.qual/class.qual/p2.cpp are
>>> desirable, or if we should suppress the missing ‘typename’ diagnostic when
>>> we’re already recovering on X<T>::X<T>. I’m open to suggestions :-)
>>>
>>> Ben
>>>
>>> <pr16909.patch>
>>
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
