Can't use template aliases in LLDB

+lldb-dev@cs.uiuc.edu since this is of general interest.

A little background: template aliases are a new C++11 feature. If you aren’t familiar with it, then the simple TL;DR version of it is that it’s like a template typedef. The syntax for using one looks like this:

template
using Foo = std::list // Foo is the same as std::list now.

Up until last weekend, LLVM’s minimum toolchain requirement was MSVC 2012, which did not support template aliases at all, so they were banned. Last weekend we upgraded the minimum required version to MSVC 2013, which we thought would allow template aliases to be used. Unfortunately, this is not the case. A base install of MSVC 2013 with no updaets will still not compile template aliases. I believe we’re actually requiring MSVC 2013 Update 4 as the baseline, but sadly this doesn’t fix the problem. A fully updated MSVC 2013 will compile them, but generate incorrect code. This is more sinister, since it means you can use them, but the code won’t work.

As a result, template aliases are still banned until we upgrade the minimum required version to 2015, which will still be a while as it’s not officially out yet. Please keep this in mind and try not to use them when writing new code. Thanks!

I removed the alias template from GDBRemoteCommunicationServerCommon.h but there are still some template aliases in the code base. Based on my first check (not necessarily complete) I find two more usage of template aliases in source/Core/Mangled.cpp lines 4867 and 4868. I have no idea about how that part of the code works and if it can cause any issue with MSVC or not but we should consider removing it also (it is in the code base since 2013-10-30).

Tamas

That code is actually from a copy of the llvm cxa_demangle.cpp (look at the comment around line 33 of that file.

We had to include this because the demangler that shipped with the system for certain OS X releases crashed for some bad input. We couldn't get a fix into the OS right away, so we put a fixed version into lldb. You will only use it if you define LLDB_USE_BUILTIN_DEMANGLER, presumably you wouldn't do that on Windows.

I don't think we need to muck with this code...

Jim

Yea I figured this wasn’t going to be a problem because the demangling path on Windows is like 10 lines to call into a Windows API to demangle for us. On the other hand, it looks like an easy fix to change it to not use template aliases. But since for all practical purposes Windows is the only platform that this matters for, I guess someone who is more of a style guide purist than me would have to make the change as I’m not motivated enough to do so. Looks like just a couple of simple replacements though.

As long as we don’t use template aliases for new code going forward though, I’m happy. They’re mostly just syntactic sugar anyway, so they’re never necessary to achieve something that you couldn’t do otherwise.

As an aside, we also use this on FreeBSD, as the system demangler
currently has some shortcomings and fails to demangle certain sysmbols
(but doesn't crash, at least).

As this code is literally a copy of demangler sources from another project with strategic bug fixes I would recommend leaving it as is. It is possible that it will be replaced wholesale from time to time until I find the time to finish replacing it with the fast demangler.

Kate Stone k8stone@apple.com
 Xcode Runtime Analysis Tools

FWIW there’s been some discussion on this side about writing a new ABI-agnostic demangler and putting in LLVM. That seems like the more logical place for any kind of demangler, so hopefully we can coordinate so that we don’t duplicate effort.

The new demangler was introduced in LLDB because while it does not yet support the full Itanium ABI C++ mangling specification, LLDB often demangles huge numbers of symbols to enable friendly breakpoint matching commands. So it made sense to have a “fast path” even while a full replacement wasn’t yet available. I think it makes a lot of sense to migrate the project to LLVM once it covers more of the mangling specification.

I would be happy to correspond with anyone who is considering contributing to the effort.

Kate Stone k8stone@apple.com
 Xcode Runtime Analysis Tools

+David Majnemer