www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 270] New: Compiler allows and crashes on typedefs of "immediate"-function types

reply d-bugmail puremagic.com writes:
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.


--
Jul 29 2006
next sibling parent Don Clugston <dac nospam.com.au> writes:
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.
Jul 31 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=270


bugzilla digitalmars.com changed:

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





Fixed DMD 0.164


--
Aug 11 2006
prev sibling next sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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


-----BEGIN PGP SIGNATURE-----

iD8DBQFE4bgSLK5blCcjpWoRAp3+AJsFKx96ZcXQhdRZ63edKQwKRUnE6QCfby6k
mowRlio1tzWR9pZl65Gp+FA=
=G6XF
-----END PGP SIGNATURE-----
Aug 15 2006
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=270


brunodomedeiros+bugz gmail.com changed:

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





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
}


--
Aug 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Aug 15 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Aug 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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
Aug 16 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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?


not *marked* as fixed, the original example became (mysteriously?) fixed 
on one of the DMD releases, and the new example is 7 comments deep.



 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
Aug 16 2006
parent Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:

 Walter Bright wrote:

 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?


Thomas' cross referencing of bugzilla with dstress makes a lot of sense.
Aug 16 2006
prev sibling parent d-bugmail puremagic.com writes:
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





Spawned new bug and reverted this one to: Fixed DMD 0.164


--
Aug 15 2006