unresolved-names with resolved prefixes

[zygoloid]

Previously: http://sourcerytools.com/pipermail/cxx-abi-dev/2015-October/002867.html

I think the problem here does not only affect substitutable prefixes for unresolved-names. Clang and GCC also disagree about how to mangle this:

inline namespace Y {
  template<typename T, typename U> struct is_same { static const bool value = false; };
  template<typename T> struct is_same<T, T> { static const bool value = true; };
}
template<bool, typename T> struct enable_if {};
template<typename T> struct enable_if<true, T> { typedef T type; };

template <class T> typename enable_if<is_same<T, float>::value, float>::type arg(T __re);
float f = arg<float>(0);

... where GCC gives _Z3argIfEN9enable_ifIXsrN1Y7is_sameIT_fEE5valueEfE4typeES3_ (which doesn't match the grammar in the ABI), and Clang gives _Z3argIfEN9enable_ifIXsr7is_sameIT_fEE5valueEfE4typeES1_ (which can collide with a different function in a different TU).

I think GCC's approach is closer to being the right one. If we can resolve an initial portion of an <unresolved-name>, we should emit the fully-qualified path to the resolved component. Though there are some other open questions here: is the partially-resolved name substitutable? (Do we get S1_ or S3_ at the end of the mangling?) Does it receive a leading N, per GCC's mangling, or no leading N, per Clang's mangling / the ABI?

[zygoloid]

Another example:

inline namespace A { template<typename T> struct X { static const int value = 1; }; }
template<typename T> void f(decltype(X<T>::value)) {}
void g() { f<int>(0); }

Clang mangles f<int> as _Z1fIiEvDtsr1XIT_EE5valueE. Note that this mangling does not mention A. If another TU contains the same content with A replaced by B, we will get a mangling collision, despite the program being valid (the non-dependent name X refers to two different entities in the two different declarations, so the two definitions of f are different templates).

[umanwizard]

This is being discussed on the GCC bug tracker -- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413

[jicama]

Effectively, GCC is using a non-standard

   ::= sr <name> <base-unresolved-name>

production to get the results you're seeing, as a generalization of the standard

   ::= sr <unresolved-type> <base-unresolved-name>
   ::= srN <unresolved-type> <unresolved-qualifier-level>+ E <base-unresolved-name>

productions. This seems to me to be more consistent than the standard

   ::= [gs] sr <unresolved-qualifier-level>+ E <base-unresolved-name>  

production, and has the benefit of getting the usual substitution behavior.

I would just grumble and fix my compiler if not for @zygoloid's point that the standard behavior leads to mangling collisions. I think we do need to mangle the enclosing scope, and could do that for affected code either the GCC way or by adding more <unresolved-qualifier-level>.

[jicama]

This also affects fully-resolved names like std::declval, which some compilers mangle using the last production of <unresolved-name> for lack of any other specification; why should that be mangled as sr3stdE7declval rather than srSt7declval? Why can we only use substitutions for unresolved types?

(Note that GCC currently omits the std:: entirely, I'm looking at these issues in the context of fixing that bug)

[jicama]

Looking back at when this grammar was introduced in 2010 ("Proposed ABI changes for new C++0x SFINAE rules"), I see that previously the mangling was

  ::= sr <type> <unqualified-name>

And that's what G++ still uses. The rationale for the change was handling names on the RHS of . and ->, where (we have now reaffirmed that) lookup of the first name needs to happen in the scope of the object expression, and so all we have is a sequence of names. There wasn't really any discussion back then about applying this change to qualified-ids outside of class member access expressions, and I think doing so was a mistake. The old mangling is still better in other contexts, as demonstrated by Richard's original post above; we know the exact scope, so how it was written is not relevant to declaration matching or SFINAE, but uniquely identifying the named entity is.

The other problem with the change is that it created an ambiguity between the old and new manglings: A::x was mangled as sr1A1x and then sr1AE1x, making it hard for demanglers to handle both, as seen in the cpp_demangle issue above.

If we're going to change the mangling ABI for qualified-ids outside class member access expressions anyway, to mangle the resolved scope instead of the written scope, I think it makes sense to express the scope the same way we do elsewhere, i.e. as <type> (mangling a namespace scope as a type).

The smallest change for G++ would be to revert the change for names with known scope, and change the mangling for qualified-ids in a class member access expression:

<unresolved-name> ::= [gs] <base-unresolved-name>   # x or (with "gs", for the function in a call) ::x
  ::= sr <type-or-namespace> <base-unresolved-name> # T::x / decltype(p)::x / A::B::x
  ::= srX <unresolved-qualifier-level>+ E <base-unresolved-name>  # A::x after . or ->

But this would reintroduce the demangler confusion, so it's probably not a good choice.

Alternatively, we could introduce a distinct mangling for the <type> mangling in the ambiguous case, so that A::f on the RHS of ./-> would continue to be sr1AE1f, but in other contexts would be srX1A1f:

<unresolved-name> ::= [gs] <base-unresolved-name>   # x or (with "gs", for the function in a call) ::x
  ::= srX <unqualified-name> <base-unresolved-name> # A::x (if no substitution for A)
  ::= sr <type-or-namespace> <base-unresolved-name> # T::x / decltype(p)::x / A::B::x
  ::= sr <unresolved-qualifier-level>+ E <base-unresolved-name>  # A::x after . or ->

Incidentally, it seems to me that [gs] is only needed to distinguish ::fn(args) from fn(args); it is not relevant to SFINAE in other contexts. Even in the class member access context, explicit global scope means we know the actual scope, so we can use the rules for fully-resolved scope.

Alternatively, we could continue with the current mangling grammar, and only say that we mangle the full scope. That would avoid changing the ABI for names that are explicitly fully-qualified, but I don't know how useful that is; in libstdc++, at least, the only mangled names that use sr are of the pattern above, where G++ mangles the namespace where the name is found (std::) and Clang does not, so it would be a change for Clang either way.

[jicama]

Or, instead of srX, use N/E even for a single level of qualification:

<unresolved-name> ::= [gs] <base-unresolved-name>   # x or (with "gs", for the function in a call) ::x
                  ::= sr <unresolved-type> <base-unresolved-name>     # T::x / decltype(p)::x
                  ::= sr <substitution> <base-unresolved-name> # previously seen scope::x
                  ::= srN <prefix> E <base-unresolved-name> # T::N::x /decltype(p)::N::x / A::x other than after . or ->
                  ::= sr <unresolved-qualifier-level>+ E <base-unresolved-name>  # A::x after . or ->

The third rule could be replaced by a note that the <substitution> in <unresolved-type> is (now) any substitution, not just a substitution for a template parm or decltype.

This shouldn't require any changes to currently conforming demanglers.

[rjmccall]

I think [gs] sr <unresolved-qualifier-level>+ E <base-unresolved-name> was only supposed to be used for an unresolved qualified name on the RHS of a member access, so if we changed the mangling of other names, well, that was a mistake and we shouldn't have done that.

If I might summarize the discussion above, it seems like we have this:

• Ensuring that different templates mangle differently in different translation units generally requires us to mangle every non-dependent reference as a fully-resolved entity. The current unresolved-name grammar fails at this: resolved names in qualifiers on unresolved names are not mangled as entity references.
• Reasonable demangling — and, probably, avoiding some really obscure collisions — requires the grammar to be clear about whether it's mangling a dependent or non-dependent name. The current unresolved-name grammar might not fail at this formally, but only because it doesn't mangle non-dependent names as entities, which as discussed above is problematic.

So we need to find a way to mangle scope qualifiers on unresolved names with as much of the name resolved as possible, and we need to do it without introducing ambiguities, and ideally we don't change existing manglings too much. Fundamentally I think that leaves us with Jason's idea of going back to <type> <unresolved-name>, but we might need to be less ambiguous.

[jicama]

I would really like to resolve this issue at the same time as adding constraint mangling, since constraints will have a lot of references to resolved names (of concepts). Any thoughts about my last proposal?