http://d.puremagic.com/issues/show_bug.cgi?id=270

           Summary: Compiler allows and crashes on typedefs of "immediate"-
                    function types
           Product: D
           Version: 0.163
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid, ice-on-invalid-code, spec
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: daiphoenix@lycos.com


Compiler allows and crashes on typedefs of "immediate"-function types,
where "immediate-function" types are non-pointer function types.
Code example:

  typedef int ft(int);
  //typedef typeof(test) fp; // This alternative typedef also crashes

  void test()
  {
    ft[10] a;
  }

---
This raises the issue: should a typedef of an "immediate" function type even be allowed? Seems to me not, as one can't use the typedef for any declaration!

((
While we're at it, should storage attributes be allowed in a typedef? Like:
"typedef static const final override auto int sometype;" ?
It also seems to me not.
))

Whichever the case (even without changes), the spec grammar should also be corrected. An example of a current doc error is:

        typedef Decl
  Decl:
        ...
        BasicType Declarator FunctionBody

but the compiler does not accept typedefs with function bodies.


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=270
> 
>            Summary: Compiler allows and crashes on typedefs of "immediate"-
>                     function types
>            Product: D
>            Version: 0.163
>           Platform: PC
>         OS/Version: Windows
>             Status: NEW
>           Keywords: accepts-invalid, ice-on-invalid-code, spec
>           Severity: normal
>           Priority: P2
>          Component: DMD
>         AssignedTo: bugzilla@digitalmars.com
>         ReportedBy: daiphoenix@lycos.com
> 
> 
> Compiler allows and crashes on typedefs of "immediate"-function types,
> where "immediate-function" types are non-pointer function types.
> Code example:
> 
>   typedef int ft(int);
>   //typedef typeof(test) fp; // This alternative typedef also crashes
> 
>   void test()
>   {
>     ft[10] a;
>   }
> 
> ---
> This raises the issue: should a typedef of an "immediate" function type even be
> allowed? Seems to me not, as one can't use the typedef for any declaration!

You can make a pointer to it.

ft * p;

But I agree that there doesn't seem to be any need for it. I find those declarations terribly confusing. I think it's another one of the silly C corner cases that we'd be better off without.

Also, it's worth considering entirely removing C-style function declarations from D, now that we have the htod tool. My experience in manually converting the Windows API headers was that there is negligible effort involved in converting to D 'function' declarations, anyway.

http://d.puremagic.com/issues/show_bug.cgi?id=270


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #2 from bugzilla@digitalmars.com  2006-08-11 19:16 -------
Fixed DMD 0.164


-- 

d-bugmail@puremagic.com schrieb am 2006-07-29:
> http://d.puremagic.com/issues/show_bug.cgi?id=270

> Compiler allows and crashes on typedefs of "immediate"-function types,
> where "immediate-function" types are non-pointer function types.
> Code example:
>
>   typedef int ft(int);
>   //typedef typeof(test) fp; // This alternative typedef also crashes
>
>   void test()
>   {
>     ft[10] a;
>   }
>
> ---
> This raises the issue: should a typedef of an "immediate" function type even be allowed? Seems to me not, as one can't use the typedef for any declaration!
>
> ((
> While we're at it, should storage attributes be allowed in a typedef? Like:
> "typedef static const final override auto int sometype;" ?
> It also seems to me not.
> ))
>
> Whichever the case (even without changes), the spec grammar should also be corrected. An example of a current doc error is:
>
>         typedef Decl
>   Decl:
>         ...
>         BasicType Declarator FunctionBody
>
> but the compiler does not accept typedefs with function bodies.

Added to DStress as http://dstress.kuehne.cn/nocompile/a/alias_37_A.d http://dstress.kuehne.cn/nocompile/a/alias_37_B.d http://dstress.kuehne.cn/nocompile/a/alias_37_C.d http://dstress.kuehne.cn/nocompile/a/alias_37_D.d http://dstress.kuehne.cn/nocompile/t/typedef_17_A.d http://dstress.kuehne.cn/nocompile/t/typedef_17_B.d http://dstress.kuehne.cn/nocompile/t/typedef_17_C.d http://dstress.kuehne.cn/nocompile/t/typedef_17_D.d

Thomas

http://d.puremagic.com/issues/show_bug.cgi?id=270


brunodomedeiros+bugz@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




------- Comment #4 from brunodomedeiros+bugz@gmail.com  2006-08-15 12:40 -------
Static arrays (as the first example) now work correctly, but there is still the
same bug with dynamic arrays. (Associative Arrays seem to work correctly.)
Example:
-----
typedef int ft(int);

ft[] x;  // is allowed

void test() {
    x.length = 2;  // crashes DMD
}


-- 

d-bugmail@puremagic.com wrote:
> Static arrays (as the first example) now work correctly, but there is still the
> same bug with dynamic arrays. (Associative Arrays seem to work correctly.)

Please do not reopen bugs that are fixed. If the bug example works, then it is fixed. If a new example fails, then it is a new bug, not an old one.

Walter Bright wrote:
> d-bugmail@puremagic.com wrote:
>> Static arrays (as the first example) now work correctly, but there is still the
>> same bug with dynamic arrays. (Associative Arrays seem to work correctly.)
> 
> Please do not reopen bugs that are fixed. If the bug example works, then it is fixed. If a new example fails, then it is a new bug, not an old one.

Hum, I was wondering about that, but then what constitutes a new and "old" example?
In other words, what are the example(s) that are part of the current bug?:
Just the one(s) in the description (with possible erratas)?
Or any example presented *before* an issue is marked as resolved? And if so, do examples where the code is not listed inline but instead is linked to an external location (such as DStress link) count as well?

I ask this for future reference, and to know what should be done with bugs 209 and 80:
http://d.puremagic.com/issues/show_bug.cgi?id=209
http://d.puremagic.com/issues/show_bug.cgi?id=80

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

http://d.puremagic.com/issues/show_bug.cgi?id=270


brunodomedeiros+bugz@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|289                         |
              nThis|                            |
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




------- Comment #5 from brunodomedeiros+bugz@gmail.com  2006-08-15 19:17 -------
Spawned new bug and reverted this one to: Fixed DMD 0.164


-- 

Bruno Medeiros wrote:
> Walter Bright wrote:
>> d-bugmail@puremagic.com wrote:
>>> Static arrays (as the first example) now work correctly, but there is still the
>>> same bug with dynamic arrays. (Associative Arrays seem to work correctly.)
>>
>> Please do not reopen bugs that are fixed. If the bug example works, then it is fixed. If a new example fails, then it is a new bug, not an old one.
> 
> Hum, I was wondering about that, but then what constitutes a new and "old" example?
> In other words, what are the example(s) that are part of the current bug?:
> Just the one(s) in the description (with possible erratas)?
> Or any example presented *before* an issue is marked as resolved? And if so, do examples where the code is not listed inline but instead is linked to an external location (such as DStress link) count as well?

As long as the examples are there or linked to before it is resolved, they are part of the current bug. If they are added after, then they are new bugs.

The reasons for this are bugs may appear to be related, but compilers can be pretty complicated, and different examples may expose completely different problems. It gets messy to try to mark a bug issue as "half resolved."

A corollary is that if a bug report has a small canonical demonstration example for it, there's no need to add any more.

> 
> I ask this for future reference, and to know what should be done with bugs 209 and 80:
> http://d.puremagic.com/issues/show_bug.cgi?id=209
> http://d.puremagic.com/issues/show_bug.cgi?id=80
> 

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> d-bugmail@puremagic.com wrote:
>>>> Static arrays (as the first example) now work correctly, but there is still the
>>>> same bug with dynamic arrays. (Associative Arrays seem to work correctly.)
>>>
>>> Please do not reopen bugs that are fixed. If the bug example works, then it is fixed. If a new example fails, then it is a new bug, not an old one.
>>
>> Hum, I was wondering about that, but then what constitutes a new and "old" example?
>> In other words, what are the example(s) that are part of the current bug?:
>> Just the one(s) in the description (with possible erratas)?
>> Or any example presented *before* an issue is marked as resolved? And if so, do examples where the code is not listed inline but instead is linked to an external location (such as DStress link) count as well?
> 
> As long as the examples are there or linked to before it is resolved, they are part of the current bug. If they are added after, then they are new bugs.
> 
> The reasons for this are bugs may appear to be related, but compilers can be pretty complicated, and different examples may expose completely different problems. It gets messy to try to mark a bug issue as "half resolved."
> 
> A corollary is that if a bug report has a small canonical demonstration example for it, there's no need to add any more.
> 

Hum, so for example, Kuehne should not list test cases in the bug comments?

According to the above, I guess I'll clone #209. Although the bug was not *marked* as fixed, the original example became (mysteriously?) fixed on one of the DMD releases, and the new example is 7 comments deep.
And #80 stays as is, then.

>>
>> I ask this for future reference, and to know what should be done with bugs 209 and 80:
>> http://d.puremagic.com/issues/show_bug.cgi?id=209
>> http://d.puremagic.com/issues/show_bug.cgi?id=80
>>


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D