Compiling D application like: ``` extern (C++) void test(string t) { }; ``` will produce error: ``` Error: Internal Compiler Error: unsupported type string ``` And there's no information about which file and line this wrong type definition is in which makes it not easy to find it if there's a lot of files and extern declarations.
This should be only a matter of using the Loc of the Dsymbol we're currently mangling when an error is thrown.
(In reply to bitter.taste from comment #1) > This should be only a matter of using the Loc of the Dsymbol we're currently > mangling when an error is thrown. I'm pretty sure it's reporting the error as "Internal Compiler Error" because the error should have been caught earlier, properly reported with file and line number.
The mangler shouldn't do the type checking.
(In reply to Jacob Carlborg from comment #2) > (In reply to bitter.taste from comment #1) > > This should be only a matter of using the Loc of the Dsymbol we're currently > > mangling when an error is thrown. > > I'm pretty sure it's reporting the error as "Internal Compiler Error" > because the error should have been caught earlier, properly reported with > file and line number. Nah, it's just that every error that's thrown from cppmangle.d is prefixed with "Internal Compiler Error" and uses Loc() as loc instead of using the one of the symbol it is trying to mangle. No type checking is done in the mangler, it's just that there's no C++ type a D `string' maps to, you could effectively prevent the use of types that have no 1:1 mapping to C++ ones but that's another matter, this approach just works (TM).
Nowadays a good loc is reported and there's no ICE, see https://run.dlang.io/is/6JhfXs