r198497 - Move MS predefined type_info out of InitializePredefinedMacros
Alp Toker
alp at nuanti.com
Sat Jan 4 22:46:48 PST 2014
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.
Landed the '::type_info' fix itself in r198548.
Also ready to go on the name change patch when I get an all-clear..
Alp.
>
> 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
More information about the cfe-commits
mailing list