Bug 6235 – Regression(2.053) ICE on typeof(Range.init[0..$]) inside a templated struct/class
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
Other
OS
Windows
Creation time
2011-07-01T13:51:00Z
Last change time
2011-11-03T23:56:14Z
Keywords
ice-on-valid-code
Assigned to
nobody
Creator
sandford
Comments
Comment #0 by sandford — 2011-07-01T13:51:56Z
This is a regression between DMD 2.052 and DMD 2.053. Here is a very reduced test case:
struct Bug(Range) { pragma(msg, typeof(Range.init[0..$]) ); }
void main(string[] args) {
Bug!(ubyte[]) bug;
}
The issue also effect classes and is statements, i.e.
enum useSlicing = is(typeof(Range.init[0..$]) : const ubyte[] );
This problem seems to be limited to the use of a template parameter inside a struct/class defined outside of the current scope. All of the following compile:
void main(string[] args) {
pragma(msg, typeof((ubyte[]).init[0..$]) );
alias ubyte[] Range;
pragma(msg, typeof(Range.init[0..$]) );
struct NotBug(Range2) { pragma(msg, typeof(Range2.init[0..$]) ); }
NotBug!(ubyte[]) notBug;
}
This bug can be worked around by placing the statement inside its own sub-template. I.e:
struct Bug(Range) {
template UseSlicing(__Range) {
enum UseSlicing = is(typeof(__Range.init[0..$]) : const ubyte[] );
}
pragma(msg, UseSlicing!Range);
}
Comment #1 by clugdbug — 2011-07-01T14:36:38Z
It's crashing in VoidInitializer::toDt(). Seems that 'type' hasn't been set.
Comment #2 by yebblies — 2011-07-01T22:16:36Z
Using $ seems to be adding the declaration to the struct as a field.
Is there any reason $ is always a variable, not just re-written as
exp[... $ ... ] => exp[... exp.length ...] ?
Comment #3 by clugdbug — 2011-07-03T13:41:49Z
(In reply to comment #2)
> Using $ seems to be adding the declaration to the struct as a field.
> Is there any reason $ is always a variable, not just re-written as
> exp[... $ ... ] => exp[... exp.length ...] ?
I think it's because exp may have side effects, so it should only be evaluated once.
Comment #4 by yebblies — 2011-07-04T01:05:23Z
(In reply to comment #3)
> > exp[... $ ... ] => exp[... exp.length ...] ?
>
> I think it's because exp may have side effects, so it should only be evaluated
> once.
Ah, of course.
Can you see anything wrong with rewriting it as:
(auto __tmp = exp, __tmp[... __tmp.length ...])
I'll have to dig into it to be sure, but I think something like this would solve a lot of the problems caused by __dollar.
Comment #5 by clugdbug — 2011-07-04T06:00:57Z
(In reply to comment #4)
> (In reply to comment #3)
> > > exp[... $ ... ] => exp[... exp.length ...] ?
> >
> > I think it's because exp may have side effects, so it should only be evaluated
> > once.
>
> Ah, of course.
> Can you see anything wrong with rewriting it as:
> (auto __tmp = exp, __tmp[... __tmp.length ...])
Not sure. There might be problem if exp defines postblit.
> I'll have to dig into it to be sure, but I think something like this would
> solve a lot of the problems caused by __dollar.