Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing mangling specification for parenthesized unresolved names #188

Open
hubert-reinterpretcast opened this issue Jul 20, 2024 · 3 comments

Comments

@hubert-reinterpretcast
Copy link

Consider the following case:

struct A {
  operator char *();
};

inline namespace N {
  char x(char *);
}
inline namespace M {
  char x(long long *);
}

template <typename T> void f(char (*)[sizeof (x)(T{})]) {}
template <typename T> void f(char (*)[sizeof x(T{})]) {}

short x(const A &);

void g(char (*p)[sizeof(char)]) { f<A>(p); }
void h(char (*p)[sizeof(short)]) { f<A>(p); }

What scope the name x belongs to is necessary unknown in the context of the calls from the template definitions.
As can be seen, both functions are callable with the same template arguments.
I do not see anything in the specification that provides a mangling for the parenthesized name.

Clang appears to handle this by using cp in place of cl for the call expression; however, this solution does not exactly handle the case where a unary & operator either forms a pointer or a pointer-to-member:

struct A { int x; };

char q(int *);
short q(int A::*);

template <typename T>
int f(char (*)[sizeof(q(&T::x))]) { return 1; }

template <typename T>
int f(char (*)[sizeof(q(&(T::x)))]) { return 2; }

int g(char (*p)[sizeof(char)] = 0) { return f<A>(p); }
int h(char (*p)[sizeof(short)] = 0) { return f<A>(p); }
@hubert-reinterpretcast
Copy link
Author

Clang's cp versus cl is consistent with the specification's Dt versus DT treatment. Doing something similar with an alternative to the ad operator name is a reasonable resolution.

@zygoloid
Copy link
Contributor

zygoloid commented Oct 3, 2024

Clang's cp mangling was agreed on the old mailing list back in 2011. Looks like it never made it into the ABI document, though.

For &(dependent qualified-id), how about we add <operator-name> ::= ap for unary & with a dependent qualified-id as operand?

@rjmccall
Copy link
Collaborator

rjmccall commented Oct 6, 2024

That seems reasonable to me. And yeah, we should add the old mangling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants