r198497 - Move MS predefined type_info out of InitializePredefinedMacros

Alp Toker alp at nuanti.com
Tue Jan 14 06:57:27 PST 2014


So the MSVCCompat part of the rename is landed, r199209.

I'm holding back on the more intrusive MicrosoftExt part because I think 
we've in fact already achieved the distinction we wanted:

|LANGOPT(MSVCCompat        , 1, 0, "Microsoft Visual C++ full 
compatibility mode")||
||LANGOPT(MicrosoftExt      , 1, 0, "Microsoft C++ extensions")|

Alp.



On 05/01/2014 05:20, Alp Toker wrote:
> On 04/01/2014 21:07, David Majnemer wrote:
>> 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)
>
> Attached patch does the mechanical regex replace described above, 
> passed through clang-format.
>
> The only manual changes are in LangOptions.def, where the MSVC-related 
> options are brought closer together with updated descriptions:
>
> LANGOPT(MSVCExt           , 1, 0, "Microsoft extensions")
> LANGOPT(MSVCCompat        , 1, 0, "Microsoft Visual C++ quirks mode")
>
>>
>> This makes it more clear what should happen with 'struct type_info', 
>> it is a non-conforming extension and should be controlled by MSVCCompat.
>
> It looks like there were plenty of others like type_info using the 
> wrong option. Needs an audit after the renaming.
>
> Alp.
>
>
>
>>
>>
>>
>> On Sat, Jan 4, 2014 at 11:41 AM, Alp Toker <alp at nuanti.com 
>> <mailto: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 <mailto: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 <mailto:cfe-commits at cs.uiuc.edu>
>>         http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>>     --     http://www.nuanti.com
>>     the browser experts
>>
>>
>

-- 
http://www.nuanti.com
the browser experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140114/68612792/attachment.html>


More information about the cfe-commits mailing list