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
