digitalmars.D.bugs - [Issue 270] New: Compiler allows and crashes on typedefs of "immediate"-function types
- d-bugmail puremagic.com Jul 29 2006
- Don Clugston <dac nospam.com.au> Jul 31 2006
- d-bugmail puremagic.com Aug 11 2006
- Thomas Kuehne <thomas-dloop kuehne.cn> Aug 15 2006
- d-bugmail puremagic.com Aug 15 2006
- Walter Bright <newshound digitalmars.com> Aug 15 2006
- Bruno Medeiros <brunodomedeirosATgmail SPAM.com> Aug 15 2006
- Walter Bright <newshound digitalmars.com> Aug 16 2006
- Bruno Medeiros <brunodomedeirosATgmail SPAM.com> Aug 16 2006
- Walter Bright <newshound digitalmars.com> Aug 16 2006
- d-bugmail puremagic.com Aug 15 2006
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
Don Clugston <dac nospam.com.au> 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
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 --
Aug 11 2006
-----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
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 } --
Aug 15 2006
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
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
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
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
Aug 16 2006
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.
Thomas' cross referencing of bugzilla with dstress makes a lot of sense.
Aug 16 2006
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 --
Aug 15 2006