On 23 January 2014 11:52, John McCall <[email protected]> wrote: > On Jan 21, 2014, at 2:01 PM, Richard Smith <[email protected]> > wrote: > > On 21 January 2014 09:36, John McCall <[email protected]> wrote: > >> 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. >> > Yep, that's what I meant. Thanks!
> We could generalize this slightly to > > <type> ::= U <source-name> <template-args> <type> > > to allow multiple arguments (as types or expressions), dependent pack > expansions, and so on. > > > That’s a bit more future-proof, I suppose, although I think it might > stretch the definition of a type-qualifier to embed anything other than a > value, and value pack-expansions are already part of the <expression> > grammar. You’re really asking for a “allow an arbitrarily complex type to > be manufactured here” mangling. > > 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. > > > It's not proposed for standardization with this syntax, and it's likely > that the final semantics will differ from the Clang extension in some ways > (the proposed partial ordering rules for constraints are rather more > complex, for instance), but it's close enough that it's an option worth > considering. > > > Unless the feature is likely to diverge so much that it won’t even be an > expression anymore, I don’t think this poses any problem for the ABI. > Vendor hat on, I reserve the right to make my extension behave differently from anything that's been standardized. As long as I can slip a vendor extension particle into the mangled name I'll be happy to use otherwise normal mangling. If it turns out I don't have to, all the better, but I'm not banking on it. Do you want me to try to prepare a patch for template constraints? I think it would look similar to my strawman proposal, except that I'd pick some other available letter? Nick
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
