https://issues.dlang.org/show_bug.cgi?id=13775

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #1 from hsteoh@quickfur.ath.cx ---
I don't think any ICE is ever deliberate! :-) It's probably a breakage caused by fixing other parts of the compiler.

--

https://issues.dlang.org/show_bug.cgi?id=13775

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m

--- Comment #2 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(In reply to hsteoh from comment #1)
> I don't think any ICE is ever deliberate! :-) It's probably a breakage caused by fixing other parts of the compiler.

Yeah. ICEs are never added on purpose, and if they are, the compiler dev who did it screwed up royally, but it's not that hard to accidentally break something when changing something else (which is why we have the test suite to catch most of that stuff and the beta releases to try and catch what the test suite misses).

Now, as for the code, I would have thought that it would work, and if it doesn't, and that's purposeful, I have no idea what the reason would be. Certainly, I agree that if it doesn't work, it's an annoying change, even if it has a proper error message.

--

https://issues.dlang.org/show_bug.cgi?id=13775

Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com

--- Comment #3 from Vladimir Panteleev <thecybershadow@gmail.com> ---
Introduced in https://github.com/D-Programming-Language/dmd/pull/3984

--

https://issues.dlang.org/show_bug.cgi?id=13775

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice                         |
                 CC|                            |schveiguy@yahoo.com

--- Comment #4 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Is this really an ICE? Usually an ICE shows a DMD source line number where the assert happened, or a seg fault.

This looks more like a standard error message, although the "e2ir" is out of place.

I found the error message, it doesn't look like an ICE to me, just a bad error message:

https://github.com/D-Programming-Language/dmd/blob/master/src/e2ir.c#L4428

Looking through history, that message has been that way for a long time.

Clearly, it's a regression, and rejects-valid, but not ICE.

--

https://issues.dlang.org/show_bug.cgi?id=13775

--- Comment #5 from Vladimir Panteleev <thecybershadow@gmail.com> ---
I believe this is an ICE, because such errors should be raised in the frontend, and not the glue layer. But I'm not a DMD hacker.

--

https://issues.dlang.org/show_bug.cgi?id=13775

--- Comment #6 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Usually ICE errors are either seg-faults or marked as ICE.

"Intentional" ICE, that is, those caught by the compiler asserts print the DMD source line. Look through the code just in the e2ir.c file.

This clearly is not *intended* to be an ICE, even if it is technically one (and of that I'm not sure).

But the error message needs to be changed regardless, the "e2ir" in the message is not helpful.

--

https://issues.dlang.org/show_bug.cgi?id=13775

Denis Shelomovskij <verylonglogin.reg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice

--- Comment #7 from Denis Shelomovskij <verylonglogin.reg@gmail.com> ---
(In reply to Steven Schveighoffer from comment #6)
> Usually ICE errors are either seg-faults or marked as ICE.

It has already been discussed. "e2ir" message is a minor ICE and it means an incorrect expression is encountered on converting expressions to IR.

--

https://issues.dlang.org/show_bug.cgi?id=13775

--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> ---
OK, so noted.

I filed a request to make this a proper ICE: https://issues.dlang.org/show_bug.cgi?id=13810

--

https://issues.dlang.org/show_bug.cgi?id=13775

Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
            Summary|Broken explicit casting of  |[REG2.067a] Broken explicit
                   |dynamic array slices of     |casting of dynamic array
                   |known size to static array  |slices of known size to
                   |of different type           |static array of different
                   |                            |type

--- Comment #9 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to Denis Shelomovskij from comment #0)
> In case it was an accept-invalid bug, what is the reason to disallow the feature and break user code without any deprecation message and with such unpleasant minor ICE message?

The expression cast(byte[2]) ubytes[0..2] would mean a combination of
- an implicit conversion T[] to T[dim] on a slice expression with CT-known
boundaries
- reinterpret cast T[n] to U[m]

When I implemented issue 3652, I didn't think about the case. So the code had been just accidentally accepted and and fortunately worked as you intended.

Then, I made the code invalid in my pull/3984 to fix some wrong-code bug.

    ubyte[4] ubytes;
    byte[3] bytes = cast(byte[3]) ubytes[2 .. 4];
    // This code had been wrongly accepted before the pull/3984.

Finally, following PR will accept such reinterpret cast only when the cast is appropriate.

https://github.com/D-Programming-Language/dmd/pull/4193


(In reply to Steven Schveighoffer from comment #4)
> Is this really an ICE? Usually an ICE shows a DMD source line number where the assert happened, or a seg fault.
> 
> This looks more like a standard error message, although the "e2ir" is out of place.
> 
> I found the error message, it doesn't look like an ICE to me, just a bad error message:
> 
> https://github.com/D-Programming-Language/dmd/blob/master/src/e2ir.c#L4428
> 
> Looking through history, that message has been that way for a long time.
> 
> Clearly, it's a regression, and rejects-valid, but not ICE.

>From historical reasons, some cast operations have been verified only by
glue-layer. That's why sometimes 'e2ir' errors are reported for invalid cast operations.

Essentially, all semantic errors should be handled by front-end layer. So I recognize it's a not-yet fixed compiler internal issue.

--

https://issues.dlang.org/show_bug.cgi?id=13775

--- Comment #10 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Kenji Hara from comment #9)
> (In reply to Steven Schveighoffer from comment #4)
> > Is this really an ICE? Usually an ICE shows a DMD source line number where the assert happened, or a seg fault.
> 
> From historical reasons, some cast operations have been verified only by glue-layer. That's why sometimes 'e2ir' errors are reported for invalid cast operations.

OK, I understand. Is there a reason not to make this assert though? The impression it gives is confusing to many people, including myself and Denis.

See issue 13810 I added.

--