You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
str is required to have a single value across translation units, so the same string literal object must be used as its initializer in all cases. For example:
The assertion here is not permitted to fail. Unfortunately, this doesn't only affect string literals appearing in inline variable initializers:
inline constexpr const char *f() { return "foo"; }
inline constexpr const char *x = f(); // must be the same string literal object in all TUs
... and templated variables expose the same issue too:
template<int> constexpr const char *x = "foo"; // x<0> must be the same pointer in all TUs
template<int> struct A {
static const char *const x;
};
template<int N> constexpr const char *A<N>::x = "foo"; // A<0>::x must be the same pointer in all TUs
I think there are two plausible solutions:
extend the existing _Z <function encoding> Es [ <discriminator> ] mangling to cover this case (note that this means we still need to number string literals within functions and classes, even though we usually don't need the number)
Consider a case such as
inline const char *str = "foo";
str
is required to have a single value across translation units, so the same string literal object must be used as its initializer in all cases. For example:The assertion here is not permitted to fail. Unfortunately, this doesn't only affect string literals appearing in inline variable initializers:
... and templated variables expose the same issue too:
I think there are two plausible solutions:
extend the existing
_Z
<function encoding>Es
[ <discriminator> ] mangling to cover this case (note that this means we still need to number string literals within functions and classes, even though we usually don't need the number)mangle the string literals based only on their contents, for example using whatever mangling scheme we settle on for mangling for non-type template arguments of class type #63 / mangling for string literals #64
I'm inclined to prefer option 2. We should probably also remove the existing mangling for string literals if we take that option.
The text was updated successfully, but these errors were encountered: