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