r198497 - Move MS predefined type_info out of InitializePredefinedMacros
David Majnemer
david.majnemer at gmail.com
Sat Jan 4 13:07:37 PST 2014
It seems that I mixed up MicrosoftMode and MicrosoftExt which lead to a
discussion between Alp Toker, Aaron Ballman, and myself.
We agreed that the current state of affairs is confusing and should be
remedied:
- MicrosoftExt will be renamed to MSVCExt (and will still be controlled by
-fms-extensions)
- MicrosoftMode will be renamed to MSVCCompat (and will still be controlled
by -fms-compatibility)
This makes it more clear what should happen with 'struct type_info', it is
a non-conforming extension and should be controlled by MSVCCompat.
On Sat, Jan 4, 2014 at 11:41 AM, Alp Toker <alp at nuanti.com> wrote:
>
> On 04/01/2014 19:09, David Majnemer wrote:
>
>> Hi Alp,
>>
>> I am working on RTTI support, a prerequisite for proper EH.
>>
>> I'm not sure why we would want to move it from MicrosoftExt. The way I
>> see it, we have MicrosoftMode for conforming extensions (__uuidof, etc.)
>> and MicrosoftExt for non-conforming extensions (extra qualification on
>> member functions, etc.). This seems like a non-conforming extension to me.
>>
>
> Thanks for the clarification David.
>
> If it's the way you describe, that indicates a naming problem -- in all
> the other clang language standards 'Ext' and 'Mode' have opposite semantics.
>
> For example, C++11 mode is the native setting, whereas C++11 extensions is
> the default setting plus C++11 language features as extensions with
> backward compatibility.
>
> Extensions enable features without changing the core semantics, whereas a
> "mode" is potentially a whole different incompatible/vendor-specific
> language dialect.
>
> In contrast, it appears that MicrosoftExt has become the native/MSVC mode
> whereas MicrosoftMode is now being used as a flag to add Microsoft
> extensions usable in conforming code.
>
> A quick grep shows they're used interchangeably, depending on who wrote
> the code.
>
> In practice it looks like comments and variable names already refer to
> MicrosoftExt as "Microsoft mode"...
>
> lib/Basic/Builtins.cpp: MSModeUnsupported = !LangOpts.MicrosoftExt
>
> ... and refer to MicrosoftMode as "Microsoft extensions" ...
>
> lib/Sema/SemaDecl.cpp: if (getLangOpts().MicrosoftMode)
> lib/Sema/SemaDecl.cpp- DiagID = diag::ext_ms_forward_ref_enum;
>
> Did we just discover a case of unchecked confusion? :-)
>
> Alp.
>
>
>
>
>> On Saturday, January 4, 2014, Alp Toker wrote:
>>
>> This is also a good starting point if anyone wants to work on MS
>> exception support.
>>
>> However while making this change it occurred to me that this
>> should be moved from MicrosoftExt to MicrosoftMode -- thoughts?
>>
>> Alp.
>>
>>
>> While making this change
>> On 04/01/2014 15:25, Alp Toker wrote:
>>
>> Author: alp
>> Date: Sat Jan 4 09:25:02 2014
>> New Revision: 198497
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=198497&view=rev
>> Log:
>> Move MS predefined type_info out of InitializePredefinedMacros
>>
>> Instead of keeping it in amongst the macros, build the
>> declaration at Sema init
>> the same way we do with other predeclared and builtin types.
>>
>> In practice this means the declaration is marked implicit and
>> therefore won't
>> show up as an unwanted user-declared type in tooling which has
>> been a
>> frequently reported issue (though I haven't been able to cook
>> up a test).
>>
>> Modified:
>> cfe/trunk/lib/Frontend/InitPreprocessor.cpp
>> cfe/trunk/lib/Sema/Sema.cpp
>>
>> Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/
>> Frontend/InitPreprocessor.cpp?rev=198497&r1=198496&r2=198497&view=diff
>> ============================================================
>> ==================
>> --- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
>> +++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Sat Jan 4
>> 09:25:02 2014
>> @@ -518,7 +518,6 @@ static void InitializePredefinedMacros(c
>> if (LangOpts.CPlusPlus) {
>> // FIXME: Support Microsoft's __identifier extension
>> in the lexer.
>> Builder.append("#define __identifier(x) x");
>> - Builder.append("class type_info;");
>> }
>> }
>>
>> Modified: cfe/trunk/lib/Sema/Sema.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
>> Sema.cpp?rev=198497&r1=198496&r2=198497&view=diff
>> ============================================================
>> ==================
>> --- cfe/trunk/lib/Sema/Sema.cpp (original)
>> +++ cfe/trunk/lib/Sema/Sema.cpp Sat Jan 4 09:25:02 2014
>> @@ -178,6 +178,13 @@ void Sema::Initialize() {
>> PushOnScopeChains(Context.getObjCProtocolDecl(),
>> TUScope);
>> }
>> + // Initialize Microsoft "predefined C++ types".
>> + if (PP.getLangOpts().MicrosoftExt &&
>> PP.getLangOpts().CPlusPlus) {
>> + if (IdResolver.begin(&Context.Idents.get("type_info")) ==
>> IdResolver.end())
>> + PushOnScopeChains(Context.
>> buildImplicitRecord("type_info",
>> TTK_Class),
>> + TUScope);
>> + }
>> +
>> // Initialize predefined OpenCL types.
>> if (PP.getLangOpts().OpenCL) {
>> addImplicitTypedef("image1d_t", Context.OCLImage1dTy);
>>
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>> -- http://www.nuanti.com
>> the browser experts
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
> --
> http://www.nuanti.com
> the browser experts
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140104/0925a4c8/attachment.html>
More information about the cfe-commits
mailing list