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 <[email protected]> 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 >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >> -- http://www.nuanti.com >> the browser experts >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> > -- > http://www.nuanti.com > the browser experts > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
