r198497 - Move MS predefined type_info out of InitializePredefinedMacros
Reid Kleckner
rnk at google.com
Tue Jan 14 14:07:16 PST 2014
Yeah, I think this is good. It makes sense in that MicrosoftExt covers
extensions that Microsoft designed and many people implement, while
MSVCCompat is specifically about compatibility with the MSVC ecosystem.
On Tue, Jan 14, 2014 at 6:57 AM, Alp Toker <alp at nuanti.com> wrote:
> 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> <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><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><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
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140114/f3104c72/attachment.html>
More information about the cfe-commits
mailing list