[Demangle] D demangler prints __T template instances as plain names, and accepts broken ones #241867

I ran into this while comparing demanglers on D symbols. When a D identifier is a template instance (it starts with __T), LLVM's D demangler doesn't expand it. It prints the mangled text as if it were an ordinary name:

$ llvm-cxxfilt _D4test10__T3fooTiZ1xi
test.__T3fooTiZ.x
$ c++filt -s dlang _D4test10__T3fooTiZ1xi
test.foo!(int).x

That one is still readable if you know the mangling. The worse case is a broken template instance. libiberty's D tests have a handful of bad inputs that should be rejected, and LLVM turns two of them into junk instead:

$ llvm-cxxfilt _D10__T4testVai _D10__T4testVbi
__T4testVa
__T4testVb
$ c++filt -s dlang _D10__T4testVai _D10__T4testVbi
_D10__T4testVai
_D10__T4testVbi

__T4testVa is an instance cut off halfway through a value argument: Va with no value after it and no closing Z. The leftover i then gets read as the variable's type, so the whole name parses and the demangler reports success on a symbol it can't actually read.

The other bad inputs in that group (_D10__T4testVi, _D8__T4test, _D11__T4testS1a) are already rejected. They only fail by luck, because nothing is left over to read as a type.

I saw this with llvm-cxxfilt 18.1.3 and 22.1.8, and with LLVM 21's dlangDemangle. parseIdentifier on main still has // TODO: Parse template instances with a length prefix., so I don't think anything has changed there.

I get that real template support is a bigger job. A cheap stopgap might be to reject an identifier that starts with __T but doesn't end in Z within its length, since a template instance always ends in Z. That would catch the two junk cases above and leave the readable output in the first example alone. Rejecting every __T identifier until templates are done would also work, at the cost of that first example.