On 27 January 2014 11:57, John McCall <[email protected]> wrote: > On Jan 24, 2014, at 7:30 PM, Nick Lewycky <[email protected]> wrote: > > On 24 January 2014 17:54, John McCall <[email protected]> wrote: > >> On Jan 24, 2014, at 5:36 PM, Nick Lewycky <[email protected]> wrote: >> >> 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. >> >> >> I completely agree that this is acceptable vendor-hat behavior and that >> the fake-qualifier idea isn’t a bad approach for 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? >> >> >> Yes, except that grammatically you should make it part of the function >> <encoding> instead of adding it to <type>. It works out to the same basic >> position. >> > > Okay, first attempt at a patch attached. Please review. > > A couple things. I chose 'Q', short for 'requires' to indicate a > constraint. I put the new part on all encodings, not just functions, > because you may need to mangle a static data member inside a class that has > a concept applied, and similarly for its vtable and special members. > > > I’m confused about what you mean by ‘concept’ here. If it's just jargon > for the enable_if feature, it seems completely counterproductive. >
Sorry, we had a miscommunication. I asked "Do you want me to try to prepare a patch for template constraints?" meaning template constraints as defined in N3701 (a.k.a, "concepts lite"), and you answered "Yes, except that grammatically you should make it part of the function <encoding> instead of adding it to <type>". I thought you had asked me to invent a mangling for concept lite, then I would use that plus a vendor extension node somewhere in the expression to indicate that what I really had was a vendor extension. What *did* you mean? Sorry for the protracted discussion. Nick We do not need to mangle enable_if conditions on class template patterns > because of the ODR (and related rules in the templates chapter). > enable_if has to be mangled for a function template because it’s part of > the template signature. You can have two function template declarations in > the scope scope with the same name and with identical template parameter > signatures and type signatures, but if they have different enable_if > conditions, then they’re considered different templates. In typical use, > this isn’t actually important: two overlapping function templates are > probably defined in the same header file, and it’s likely that every call > site will see both of them, and so any given list of template arguments > that doesn’t lead to an ambiguity will probably pick the same template > every time. But that’s not actually *required*: it’s totally fine to have > two different function templates in two different translation units that > both accept the same template arguments, and we need to distinguish them. > > But two class temploids with the same name in the same scope always > declare the same entity for the ODR’s purposes, and if a particular list of > template arguments would pick an explicit specialization > ([temp.expl.spec]p6) or partial specialization ([temp.class.spec]p1), that > specialization is required to be defined in every translation unit that > would use it. So while you can guard a template pattern with an enable_if > clause, it just controls whether that pattern is selected for > instantiation, and the decision to select that pattern doesn’t need to be > mangled in for the same basic reason that we don’t have to mangle in the > partial-specialization signature we choose: ultimately, you can never > legally simultaneously instantiate foo<int,char*> from two different > patterns. > > Now, there are concepts proposals that interfere with this along multiple > axes. There are proposals which allow you to explicitly choose between > ambiguous concept maps for a template argument, and there are proposals > which allow you to define types in a concept map that would otherwise > conflict in name with each other. Both proposals affect mangling: the > former suggests that we need to mangle a reference to the concept map as > part of the template arguments, and the latter suggests that we need to > mangle the concept map as part of the context. But in neither case does a > random expression in the <encoding> help. > > John. >
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
