Bug 4269 – Regression(2.031): invalid type accepted if evaluated while errors are gagged
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2010-06-04T05:58:00Z
Last change time
2015-06-09T05:12:02Z
Keywords
accepts-invalid, ice, pull, wrong-code
Assigned to
clugdbug
Creator
r.sagitario
Comments
Comment #0 by r.sagitario — 2010-06-04T05:58:53Z
The D2 code (tried with DMD 2.042 and 2.046):
static if(__traits(compiles,A.sizeof)) pragma(msg, "A.sizeof compiles!");
class A
{
void foo(B b);
}
compiles without error with "dmd -c test.d" or even links if foo is made final.
This is caused by the error when evaluating B is muted while processing __traits(compiles), but A is never revisited later.
A debug version of DMD outputs
ty = 37, '_error_'
assert glue.c(1059) 0
This can happen whenever globals.gag is non-zero, i.e. with speculative semantic analysis.
Comment #1 by clugdbug — 2010-06-15T07:25:53Z
Generated an error message in 2.030 and earlier.
Comment #2 by clugdbug — 2010-06-15T13:41:05Z
Here's a test case which incorrectly compiles on D1.055 and later, but generated an error on DMD1.053 and earlier.
static if(!is(typeof(A[0]))) pragma(msg, "A.sizeof doesn't compile!");
struct A {
B foo(){}
}
And this variation is ICE(glue.c) on 2.047, but generates wrong code on 2.031-2.046.
static if(!is(typeof(A[0]))) pragma(msg, "A.sizeof doesn't compile!");
struct A {
void foo(B b){}
}
Comment #3 by clugdbug — 2010-08-25T12:44:15Z
This test case it's a problem with is(), not static if. This behaviour was introduced in 2.047.
--------
enum bool WWW = is(typeof(A.x));
class A {
B blah;
void foo(B b){}
}
--------
Comment #4 by clugdbug — 2011-02-11T05:23:49Z
*** Issue 5079 has been marked as a duplicate of this issue. ***
Comment #5 by yebblies — 2011-07-10T07:33:53Z
The problem seems to be a huge forward reference bug. When semantic is first called on a declaration while errors are gagged, it is never attempted again. This leads to errors never being printed, and compilation happily continuing to code generation.
The solution is probably the same as for bug 4042 - add the ability to rewind the semantic pass on failure to each type of declaration's semantic routines.
Some fun test cases:
// Compiles without error
//static if(is(typeof(X1.init))) {}
//class X1 { Y y; }
// Compiles without error
//static if(is(typeof(X2.init))) {}
//struct X2 { Y y; }
// Assertion failure: '0' on line 1123 in file 'glue.c'
//static if(is(typeof(X3.init))) {}
//void X3(T) { }
// Compiles without error
//static if(is(typeof(X4.init))) {}
//Y X4() { return typeof(return).init; }
// Access violation in mtype.c:6819
//static if(is(typeof(X5.init))) {}
//typedef Y X5;
// Compiles without error
//static if(is(typeof(X6.init))) {}
//alias Y X6;
// Assertion failure: '0' on line 1123 in file 'glue.c'
//static if(is(typeof(X7))) {}
//Y X7;
// Compiles without error
//static if(is(typeof(X8.init))) {}
//class X8 : Y {}
// Compiles without error
//static if(is(typeof(X9.init))) {}
//interface X9 : Y {}
// Compiles without error
//static if(is(typeof(X9.init))) {}
//interface X9 { Y y; }
// Doesn't even need the errors gagged - what the hell?
// Probably a different bug
//struct X10 { alias Y this; }
// Assertion failure: '0' on line 1123 in file 'glue.c'
//static if(is(typeof(X11.init))) {}
//const { Y X11; }
// Compiles without error
//static if(is(typeof(X12.init))) {}
//enum X12 = Y;
// Compiles without error
//static if(is(typeof(X13!(0).init))) {}
//template X13(Y y) {}
// Compiles without error
//static if(is(typeof(X14.init))) {}
//struct X14 { int a; alias a this; alias a this; }
// Compiles without error
//static if(is(typeof(X15()))) {}
//auto X15() { alias x this; }
// Compiles without error
//static if(is(typeof(X16))) {}
//alias X16 X16;
Comment #6 by clugdbug — 2011-08-30T01:42:25Z
I think there are a couple of different issues here. Some involve forward referenced declarations, as you've said.
But some of these occur because they have semantic run while errors are _incorrectly_ gagged. In particular, when semantic3 is run on a function, errors shouldn't be gagged unless the function is part of a template which was speculatively instantiated. I'm halfway through a patch for this.
Comment #7 by yebblies — 2011-08-30T07:58:01Z
(In reply to comment #6)
> I think there are a couple of different issues here. Some involve forward
> referenced declarations, as you've said.
> But some of these occur because they have semantic run while errors are
> _incorrectly_ gagged. In particular, when semantic3 is run on a function,
> errors shouldn't be gagged unless the function is part of a template which was
> speculatively instantiated. I'm halfway through a patch for this.
Does your gagging solution fix the problem for all semantic passes, or just semantic3? I couldn't think of a way to do it without rewinding semantic on error, that gets error messages appearing in the right places. Since you've got it under control, I'll work on something else.
Should I close the pull request, does your patch cover that?
The whole idea of error gagging is probably bogus because of this.
I don't know what to do about it.
One possibility might be to attach gagged error messages to the symbol having semantic() run on, and then "replaying" those messages if the symbol is used outside of the gag.
My patch doesn't thoroughly fix this, it just gets it off the regression list. It outputs a generic error message.
Comment #15 by clugdbug — 2012-02-07T01:05:27Z
So far my patch fixes the original bug report, and about 60% of Daniel's extra test cases.
Comment #16 by clugdbug — 2012-02-09T07:55:58Z
Even with the new patch, this example from comment 5 :
static if(is(typeof(X3.init))) {}
void X3(T3) { }
is an ICE(glue.c) for 2.047 on. It generated an error on 2.045 and earlier. (On 2.046 it silently generated bad code). Perhaps it should be treated as a different bug.
Comment #17 by yebblies — 2012-02-09T08:08:33Z
(In reply to comment #16)
> Even with the new patch, this example from comment 5 :
>
> static if(is(typeof(X3.init))) {}
> void X3(T3) { }
>
> is an ICE(glue.c) for 2.047 on. It generated an error on 2.045 and earlier. (On
> 2.046 it silently generated bad code). Perhaps it should be treated as a
> different bug.
Yep, different bug. The crash is due to an error in a parameter type not resulting in TypeFunction::semantic returning terror. (Or at least, that and the fact it reaches code generation due to this bug.) I swear I fixed this in a pull request last year, but it must've been part of something that never got accepted.
Comment #18 by yebblies — 2012-02-10T03:17:54Z
Having a closer look at Walter's patch, this only fixes the issue for class, struct and interface declarations. From the list in comment 5, function, variable, template and alias this declarations still need to be fixed to get this off the regression list.
Don, I thought you meant you'd tested with your new patch and it still crashed - is this the case or is this only with Walter's fix? The underlying reason is the same, but when this bug is fixed the crash will disappear as it will never get to codegen.
Walter, please see the list in comment 5, everything here needs to fail before this stops being an ice/regression. Please also note that https://github.com/D-Programming-Language/dmd/commit/75ccf8c3ae057aad7128d710fe735f7772be0471 overwrote three test cases from this bug that dealt with alias and template declarations.
Comment #19 by yebblies — 2012-02-10T04:05:52Z
To be more specific - any declaration semantic routine that might result in errors needs to give an error the second time semantic is run too - the reason it happens with the X3 test case is because errors in parameter types are not propagated to the function type, but there are plenty of other errors in FuncDeclaration::semantic that will be silently ignored as the type isn't set to Type::terror. I haven't looked at the other declaration types yet but there are probably cases there too.
Some FuncDeclaration cases:
//static if (is(typeof(X17.init))) {}
//scope void X17() {}
//static if (is(typeof(X18.init))) {}
//abstract void X18() {}
//static if (is(typeof(X19.init))) {}
//override void X19() {}
//static if (is(typeof(X20.init))) {}
//const void X20() {}
//static if (is(typeof(X21.init))) {}
//immutable void X21() {}
//static if (is(typeof(main.init))) {}
//string main();
//static if (is(typeof(main.init))) {}
//auto main() { return ""; }
//static if (is(typeof(main.init))) {}
//void main(int) { }
Some of these are just accepts-invalid with meaningless attributes, but the 'main' ones will generate wrong code.
Errors in the declaration type are not all that needs to be monitored - either the error count needs to be examined or every possible error needs to set the type to Type::terror.
Comment #20 by yebblies — 2012-02-10T04:11:42Z
The approach of using Declaration::type to signal semantic failed also relies on Type::semantic returning Type::terror on every error - this is not followed everywhere.
Comment #21 by clugdbug — 2012-02-10T07:12:18Z
My upcoming patch fixes all of your cases in comment 5 except #13. My comment in comment 16 is about Walter's commit, not my patch.
But it's not quite ready, it fails some cases in the test suite related to __traits(compiles) with deprecated and purity.
I *think* I just have to do a bit more work on enabling and disabling gagging at the right time.
Comment #22 by github-bugzilla — 2012-02-11T10:26:23Z
*** Issue 6296 has been marked as a duplicate of this issue. ***
Comment #26 by clugdbug — 2012-12-13T01:05:42Z
All test cases now correctly give an error, except for case 13, which is fixed in
https://github.com/D-Programming-Language/dmd/pull/1370
There are also diagnostic problems with 3 other test cases, I have created bug 9146 for those. It is much less serious than this bug.
Comment #27 by github-bugzilla — 2012-12-13T06:46:13Z