Bug 17056 – No filename and line info for wrong extern C++ type
Status
RESOLVED
Resolution
WORKSFORME
Severity
minor
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2017-01-02T19:59:35Z
Last change time
2020-03-21T03:56:36Z
Keywords
ice
Assigned to
No Owner
Creator
Dāvis
Comments
Comment #0 by davispuh — 2017-01-02T19:59:35Z
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.
Comment #1 by bitter.taste — 2017-01-04T12:52:55Z
This should be only a matter of using the Loc of the Dsymbol we're currently mangling when an error is thrown.
Comment #2 by doob — 2017-01-04T17:22:18Z
(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.
Comment #3 by doob — 2017-01-04T17:23:23Z
The mangler shouldn't do the type checking.
Comment #4 by bitter.taste — 2017-01-04T20:32:08Z
(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).