On Jan 20, 2014, at 6:13 PM, Nick Lewycky <[email protected]> wrote: > I'm trying to mangle a vendor extension that encodes an expression which > applies to function overload candidates, with the goal that a user running > the demangler would see their expression demangled. While there are various > vendor extension points, none of them allow me to go into encoding an > expression, unless I stick a stray "decltype" in there, or similar > (expression in a template argument that doesn't actually exist, etc.). > > The vendor extension is described in full here: > http://clang.llvm.org/docs/LanguageExtensions.html#controlling-overload-resolution > . > > I don't think I can do it without an extension to the mangling rules. As a > strawman proposal, I suggest this: > > <type> ::= Ue <expression> E # vendor extended type qualifier
I think you mean <type> ::= Ue <source-name> <expression> E <type> And this would be valuable for mangling e.g. dependent address space qualifiers, if anybody ever wants to do those. However, it feels really forced to add your feature, specifically, to <type>, since it can’t appear in an arbitrary position; it’s much closer to a qualified method name. But the ref/cv-qualifiers area is only allowed in a <nested-name>, and you need to be able to do this on a top-level function, so I suppose extending <type> in a known-useful direction and then abusing <type> might be the best thing. On the other hand, isn’t this a proposed direction for standardization? I would have no problem with giving this a proper, non-vendor mangling just in case. John. _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
