| Issue |
97756
|
| Summary |
ms mangler for template values: poor nyi error messages and nyi opte pointer
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
memory-thrasher
|
## I am reporting this bug for completeness. I am actively working on a patch submission.
The official MSVC mangler lacks support for some c++ that is valid according to the standard, clang, and every decent compiler. Concerning template instance name mangling, specifically, there are presently 6 cases where the function MicrosoftCXXNameMangler::mangleTemplateArgValue gives up mangling and emits the rather unhelpful error:
> cannot mangle this template argument yet
I improved that error message on my local build to tell which of the 6 possible cases I was running into. That case is when the non-type template parameter's value is an l-value point to one-past-the-end of some constexpr array. This case is not possible in c++ code that supports the official MSVC compiler, so consistency with MSVC is both impossible and uneeded. Furthermore, templates are not generally called across an ABI boudnary, but rather, each binary contains its own instances.
I arbitrarily chose a mangling pseudonym to represent this case. I foresee two potential future issues, though both seem to me to be highly unlikely and neither, any worse than failing to compile the code in the first place.
* Compatibility between binaries output by clang using this patch, with binaries produced by some other compiler or future version of clang that might use a different arbitrary pseudonym. I doubt this case will ever happen because for the reasons already declared above; each binary should contain its own template instance with its own mangling rules.
* Collision between two template function instances of the same template function where the template argument for each is the OPTE value for two different arrays, and that is the only difference between the instances, and yet the two instances should have different behavior. I cannot think of a good reason the two functions should have different behavior when handed a pointer that is essentially invalid (does not point to a usable resource). Even a reverse iterator has better solutions.
The patch will include a minimal test case.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
