Bug 12860 – REG 2.065: typeid(_error_) symbols leaked to backend
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-06-05T22:28:00Z
Last change time
2014-06-07T02:21:29Z
Keywords
accepts-invalid, GDC, pull, wrong-code
Assigned to
nobody
Creator
ibuclaw
Comments
Comment #0 by ibuclaw — 2014-06-05T22:28:57Z
Reduced from the 2.065 testsuite:
---
void test83()
{
assert(!__traits(compiles, typeid(inout(int*) ())));
}
---
This leaks a typeid(_error_) TypeInfoDeclaration to the backend, and expects it to compile the Error symbol down to object file.
With DMD, this appears in the object file as:
.data._D10TypeInfo_@6__initZ 0000000000000010 _D10TypeInfo_@6__initZ
However, given the invalid name of the symbol, it instead causes the following error in GDC:
Assembler messages:
19: Error: junk at end of line, first unrecognised character is `@'
22: Error: junk at end of line, first unrecognised character is `_'
23: Error: expected comma after name `_D10TypeInfo_' in .size directive
24: Error: invalid character '@' in mnemonic
This is preventing GDC from updating to 2.065 frontend sources.
It's hard to track down which commit caused this, however looking at the specific test, it shows areas around these PRs:
https://github.com/D-Programming-Language/dmd/pull/3081/fileshttps://github.com/D-Programming-Language/dmd/pull/3034/files
Comment #1 by ibuclaw — 2014-06-05T22:48:34Z
Also happens with 'static assert' as well as 'assert'.
Comment #2 by k.hara.pg — 2014-06-06T04:50:13Z
Is this correct test case?
// from runnable/testconst.d, generating wrong TypeInfo from 2.065
void test83(/*inout(int) _ = 0*/)
{
static assert(!__traits(compiles, typeid(inout(int*) function(int))));
}
void main() {}
Command lines in Windows:
$ dmd test.d
$ libunres -l test.obj
BSS
CODE
CONST
DATA
FLAT
FM
FMB
FME
_BSS
_D10TypeInfo_@6__initZ <----
_D4test6test83FZv
_D6object15__unittest_failFiZv
_D6object7__arrayZ
_D6object8__assertFiZv
_DATA
_TEXT
__Dmain
_main
(In reply to Kenji Hara from comment #2)
> Is this correct test case?
>
> // from runnable/testconst.d, generating wrong TypeInfo from 2.065
> void test83(/*inout(int) _ = 0*/)
> {
> static assert(!__traits(compiles, typeid(inout(int*) function(int))));
> }
Yes, I believe it happens for all !__traits(compiles) tests in that function. Not just that particular line (ie: delegate(int))
Comment #5 by github-bugzilla — 2014-06-06T16:51:14Z