Handling legacy VC++ deficiencies

Visual Studio 2005 generated a lot of code that uses unqualified
pointers to member functions (think MFC dispatch tables; fear and
loathing, sure, but the code is out there), and even 2012 supports them,
although it now generates fully-qualified names ("&Class::Function", vs.
accepting "Function" without "&" or "Class::"). I understand C++
requires a qualified name; on the other hand, I want to compile this
corpus of legacy code with Clang (for analysis, not building).

Another issue in such legacy code is expecting inheritance of typedefs
in templates, whereas the standard requires redeclaring them explicitly
(e.g., types like value_type and pointer).

I remember seeing in another email that Clang does not want to be "bug
for bug compatible" with MSVC (and in yet another support for the bug
where VS 2005 eats a comma in varargs macros); what's the best way to
support compiling legacy code? Is it to be entirely unsupported? Can a
plugin do it? Or will changes restricted to particular Microsoft compiler
emulation (-fmsc-ver) be accepted?

Stuff like this is generally added under the -fms-compatibility,
provided there's "enough" code out there that depends on it. I'm not
sure if MFC itself uses this style, or if it's only the wizard
generated MFC code?

I think it depends heavily on the bug, how much code is affected by
it, and how trivial the changes to the source base will be. Since
this is in code generated by MSVC in a relatively "recent" version of
the compiler and is likely to affect a fair number of people, I think
it's reasonable to support the change in -fms-compatibility mode
assuming it isn't overly onerous to implement and maintain. If
there's documentation on MSDN that describes the behavior, it makes
the case stronger for supporting it.

Just my 2 cents though. :slight_smile:

~Aaron

I agree with Nikola and Aaron. If this issue affects a lot of code and the implementation does not turn the code into a mess, then I think we should consider supporting it as a compatibility option.

Visual Studio 2005 generated a lot of code that uses unqualified pointers to
member functions (think MFC dispatch tables; fear and loathing, sure, but
the code is out there), and even 2012 supports them, although it now
generates fully-qualified names ("&Class::Function", vs.
accepting "Function" without "&" or "Class::"). I understand C++ requires a
qualified name; on the other hand, I want to compile this corpus of legacy
code with Clang (for analysis, not building).

I've tackled the same problem recently. It seems that MSVC10 is actually trying to remedy the problem and does not accept unqualified names for member functions in most contexts. AFAICT, the only context in which it allows it is an initializer list -- that's what ON_MESSAGE macros resolve to. Furthermore, these macros allow both unqualified and qualified names, so there's no straightforward way to fix the MFC headers.

I've hacked around the problem temporarily by adding __ensure_memptr keyword that turns the name into a qualified id and modified MFC headers accordingly (https://github.com/avakar/clang/commit/630050d3ca361770e2d5dd690ad084b87582468f). Naturaly, I'd rather have clang accept the unqualified id in MS mode directly, so +1 for the request.

Another issue in such legacy code is expecting inheritance of typedefs in
templates, whereas the standard requires redeclaring them explicitly (e.g.,
types like value_type and pointer).

This is a problem with unqualified lookup in general. MSVC performs the lookup at instantiation time and looks into dependent base classes even though it shouldn't.

Another issue to be aware of: http://llvm.org/bugs/show_bug.cgi?id=12705

Please file bugs about all of these incompatibilities so we can add them to the meta bugs and track what is missing.

I’ve added a bunch of bugs, but I’ve attached them to http://llvm.org/bugs/show_bug.cgi?id=13707. Hth.

Thanks, this will make it much easier to track what we’re missing.